Re: After upgrade, what do you do about "removed" and "obsolete" packages ?
On 2024-05-28 at 15:02, Marco Moock wrote: > Am 28.05.2024 um 20:38:46 Uhr schrieb Thomas Schmitt: >> What does "[residual-config]" mean ? > > Packages include system-wide configuration files. If packages are > removed, this configuration will not be deleted. You need to purge > such packages to remove it. On brief analysis, it looks like this reflects the same status which is reported in the Status line of the output of 'dpkg -s PACKAGENAME' with the string "deinstall ok config-files". YMMV, but I find that intuitive enough: the package used to be installed, and isn't anymore, but its config files have been left behind. (Note that if you have the package installed from multiple architectures, you will apparently need to specify the arch qualifier suffix to the package name in order for the command to not error out.) I don't remember using that dpkg command very often, but I do remember seeing that string often enough in the past, so there are probably other commands which will also report it if applicable. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Security hole in kernel fixed?
On 2024-05-15 at 03:05, Hans wrote: > Dear developers, As usual, most of us here are not Debian developers, even if some of us may be software developers. > in April 2024 the security hole CVE-2023-6546 was discovered in linux-image, > and I believe, it > is fixed in kernel 6.1.0 (from debian/stable) as soon after this a new kernel > was released. > > However, there is no new kernel 6.5.0-*-bpo released at that time, so my > question: > > Does anyone know, if this fix was also integrated in kernel 6.5.0-*.bpo ? I don't have a definitive answer, but you might look at: https://security-tracker.debian.org/tracker/CVE-2023-6546 The only place it mentions 6.5 is in the Notes section, where it mentions 6.5-rc7 (with a kernel.org link) in the context of a statement that the Linux kernel in Debian buster does not include the vulnerable code. I would therefore suspect that any 6.5.x kernel probably was not affected by this vulnerability to begin with. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: large complaint / very urgent
On 2024-04-29 at 03:13, to...@tuxteam.de wrote: > On Mon, Apr 29, 2024 at 06:03:46AM +, crackmap wrote: > >> hello >> >> large complaint > > But in the wrong direction, in many ways. > >> Please forward this mail to the Debian department; Update and Upgrade > > There is no "Debian department" -- this is a volunteer project. > Help out! I think you've misinterpreted this sentence slightly; I think it could have been validly rephrased as >> Please forward this mail to the "Update and Upgrade" department of >> Debian" and thus been *slightly* more reasonably conceived than how you seem to have read it. The basic error of sending a complaint about Kali to Debian (much less to debian-user), however, remains. (Especially when, as noted, Debian stable-security includes 115.10 already. Debian testing, by comparison, appears to still have 115.8; possibly Kali may be based on testing?) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Marking as spam
On 2024-04-18 at 11:53, Eduardo M KALINOWSKI wrote: > On 18/04/2024 12:43, Hans wrote: > >> But the "Sorry" mail I did send without the spam tag. However, I >> get it WITH the spamtag, as all mails get the DCIM=false tag in the >> header (created by the debian servers) and megamailservers.eu add >> the SPAM tag. > > Or you could use a less shitty mail service, because failed DKIM (I > assume that's what you mean by DCIM=false) does not mean that an > email is a spam. Good luck convincing a provider which has decided to do this of that. > Conversely, I see a lot of spams that have a valid DKIM signature. > > Moreover, I don't think the Debian list servers validate DKIM. It's > probably your host that is doing so. > > And finally, your own mails fail DKIM, so for a mail server that > seems to give so much importance to DKIM, they could at least set it > up right. My understanding, based I think in part on past conversations, was/is that changes which are often made to messages automatically by mailing-list software as part of forwarding them through to the list members have the side effect of causing DKIM checks to fail (at least with some DKIM-validating configurations, I'm not sure about all). If that is correct, then not only would that likely be the reason for Hans' mail provider seeing DKIM validation failing for all mails from debian-user, it would also mean that mails from Hans would probably fail DKIM validation for those who receive them through debian-user - without meaning that his mail provider is necessarily doing DKIM wrong, at least on the sending end. A way to check that might be to have Hans send a mail to someone both via the list and not, or (if that gets filtered out by some relevant software as being a duplicate) send two mails, one via the list and the other not. If the one via the list has the header flag for failed DKIM, and the other doesn't, that would seem to narrow down the possibilities. (I am not volunteering for this.) On the other hand, if my understanding is *not* correct, then none of that applies. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Sorry
On 2024-04-18 at 11:15, Hans wrote: > Sorry, the spam tag appears because of DCIM in the header. > > Not my fault. But it did not appear on *this* message from you to the list. Is there a reason you couldn't edit the Subject: lines of the replies you're sending, before you send them, to remove the marker? If the marker were being added to the replies after you send them (which would be an odd behavior, since presumably the reason it's being added is that the mail servers think there's something odd about the mail when it's incoming, and there isn't anything odd about the mail you're *sending* except where it's addressed to), then an edit like that wouldn't do anything. But if it were being added after you send the mail, presumably it would have been added to this "Sorry" message as well - and it wasn't, even though that mail too is a reply to an E-mail you received through the list, and is addressed to the list. It would therefore seem as if editing out the "*SPAM*" marker from your replies before you send them would result in the replies showing up on the mailing list without that marker. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: tbird troubles
On 2024-04-16 at 16:56, gene heskett wrote: > On 4/16/24 10:46, The Wanderer wrote: > >> On 2024-04-16 at 10:28, Greg Wooledge wrote: >>> In his original message, he claimed that closing one window >>> makes the other one also close. >>> >>> I asked *how* he was closing them, and he said that he gets the >>> same result whether he uses the WM's close button, or the >>> application's Exit menu choice. >> >> From what I saw in a Bugzilla bug report (which I think was linked >> to in this thread?) about a similar behavior (dating back a good >> number of years, and closed as - more or less - "not meaningfully >> fixable" or the like), neither of those is what is needed. >> >> What needs to happen, according to that analysis, is to close one >> of the windows not by File -> Exit or File -> Quit, but by File -> >> Close. (In my - severely obsolete - Thunderbird version, it's near >> the top of the File menu, and has the associated keyboard shortcut >> Ctrl+W.) >> >> Reportedly, after doing that, if you then quit the program entirely >> (by any of the other available methods), when you re-launch it it >> will come up with only one window. > > Thank you, that fixed it! You're welcome. Please extend your thanks to Tomas, who is the one who tracked down the links that led to the bug report where I found the analysis and this advice, and also to Curt, who was giving the same recommendation in different terms before I got to it. All I did was read the discussion at the link Tomas provided, and find a different way to express it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: tbird troubles
On 2024-04-16 at 10:28, Greg Wooledge wrote: > On Tue, Apr 16, 2024 at 02:21:27PM -, Curt wrote: > >> Have you tried *closing* one of the two windows, *quitting* the >> remaining one, and then restarting your bird? > > In his original message, he claimed that closing one window makes > the other one also close. > > I asked *how* he was closing them, and he said that he gets the same > result whether he uses the WM's close button, or the application's > Exit menu choice. From what I saw in a Bugzilla bug report (which I think was linked to in this thread?) about a similar behavior (dating back a good number of years, and closed as - more or less - "not meaningfully fixable" or the like), neither of those is what is needed. What needs to happen, according to that analysis, is to close one of the windows not by File -> Exit or File -> Quit, but by File -> Close. (In my - severely obsolete - Thunderbird version, it's near the top of the File menu, and has the associated keyboard shortcut Ctrl+W.) Reportedly, after doing that, if you then quit the program entirely (by any of the other available methods), when you re-launch it it will come up with only one window. The situation appears to be triggered by doing one of the UI actions that causes Thunderbird to open a new "main" window - which can happen by accident, e.g. by trying to detach a tab from the main Thunderbird window (which apparently doesn't open a new window with just that tab, but rather opens an entire new main Thunderbird window with the contents of that tab active). That in turn can (I would expect) be done accidentally by trying to drag a tab to a new position in the tab bar, but unintentionally dropping it at a place which is instead treated as outside of the window. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Testing amd64 netinst LUKS+LVM install broken
On 2024-04-10 at 02:39, Andrew M.A. Cater wrote: > On Tue, Apr 09, 2024 at 05:51:26PM -0700, Craig Hesling wrote: > >> Hi all, >> >> I'm having an issue with the guided partitioner in the Debian >> testing amd64 installer. Specifically, the "Guided - use entire >> disk and set up encrypted LVM" errors out and emit the following >> error message: >> >> partman-lvm: pvcreate: error while loading shared libraries: >> libaio.so.1: cannot open shared object file: No such file or >> directory The fact that this is libaio catches my eye. > Hi, > > I suspect that Debian Testing _might_ be uninstallable just at the > moment. There's a large scale migration and change of packages (to do > with securing a workable time implementation post-2038 and moving > from 32 bit values). > > That's taken a lot longer than expected: Debian Unstable and > therefore Debian Testing have been hit. It's just possible that this > library is caught up in the dependencies. Yes, this is almost certainly what's going on. libaio is one of the small handful of libraries (that I'm aware of) for which the 't64' version of the package appears to have slipped through the cracks on the measures being taken to prevent things from migrating to testing until the transition is properly ready. $ apt-cache search libaio libaio-dev - Linux kernel AIO access library - development files libaio1 - Linux kernel AIO access library - shared library libaio1t64 - Linux kernel AIO access library - shared library $ apt-cache search t64 | egrep '^lib[^ ]+t64 ' | cut -d ' ' -f 1 libfyba0t64 libglibmm-2.68-1t64 libaio1t64 libnetcdf19t64 libudns0t64 > This will resolve itself in due course - but it might be better to > install a minimal stable and then upgrade to testing later. > > Be aware also that the problematic version of xz libraries is also in > Debian testing - someone else pointed this up the other day. For some values of "the problematic version". The one that is *known* to be backdoored has been reverted: $ apt-cache policy xz-utils xz-utils: Installed: 5.6.1+really5.4.5-1 Candidate: 5.6.1+really5.4.5-1 Version table: *** 5.6.1+really5.4.5-1 900 900 http://ftp.us.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status However, while the version reverted *to* in this case - 5.4.5 - is from prior to the introduction of the known backdoor, it *is* from well after the now-apparent bad actor began contributing to the upstream project, and there is discussion of possibly needing to revert to as far back as a 5.2.x version in order to be completely sure of not having any commits that come from that bad actor. (If there's a detail I've missed catching which would mean that any of that is inaccurate, I would be pleased if someone would point it out to me.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Dependency meaning
On 2024-03-21 at 05:02, Detlef Vollmann wrote: > This is essentially a follow-up on my question about the > 64bit time_t transition. > I'm trying to upgrade some packages manually. > For this, I'm trying to understand the dependencies. > > 'apt-cache showpkg libssl3t64' gives me this: You might also try 'apt-cache show libssl3t64', and compare the dependency-related parts of the results. >> Dependencies: >> 3.1.5-1.1 - libc6 (2 2.34) libssl3 (3 3.1.5-1.1) openssh-client (3 1:9.4p1) >> openssh-server (3 1:9.4p1) python3-m2crypto (3 0.38.0-4) libssl3 (0 (null)) >> libssl3:i386 (3 3.1.5-1.1) libssl3:i386 (0 (null)) openssh-client:i386 (3 >> 1:9.4p1) openssh-server:i386 (3 1:9.4p1) python3-m2crypto:i386 (3 0.38.0-4) >> libssl3t64:i386 (35 3.1.5-1.1) libssl3t64:i386 (38 3.1.5-1.1) > > I'm trying to understand, what the numbers in parentheses mean. > The second numbers are obviously version numbers. > I guess the first numbers are dependency types, but I have no idea, > what they mean. > The man page says "For the specific meaning of the remainder of the > output it is best to consult the apt source code." > I'd like to avoid this. Can anybody point me to a list what these > numbers mean? I don't think I even knew 'showpkg' was a verb for apt-cache, before this. That said, by comparing against the output of 'apt-cache show' for the same package name: it looks as if '2' is 'Depends:' and '3' is 'Breaks:'. I'm less sure about '35' and '38', but they might be 'Replaces:' and 'Provides" in some order. I was actually running the commands against the non-'t64' version of the package, because the one with that suffix isn't available in my configured repositories yet. That one doesn't include the '0' dependencies. Based on the fact that those dependencies are listed for the 't64' version of the package, my guess is that '0' is 'Conflicts:'. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bookworm Fasttrack and Virtualbox
On 2024-03-17 at 08:48, Greg Wooledge wrote: > On Sun, Mar 17, 2024 at 12:35:33PM +0100, Miguel A. Vallejo wrote: > >> Well... it seems my brain can't distinguish Bookworm from >> Bullseye. > > It's not just you. The use of three "b" names in a row (buster, > bullseye, bookworm) was in my opinion a poor decision. I tend to concur. The closest thing to a helpful mnemonic for it that I've found (which isn't very close, and often isn't very helpful, given how frequently I fail to remember it when I would need it) is that the names are in reverse alphabetical order. > I've taken to calling the releases by their numbers (10, 11, 12) > instead of their codenames to avoid confusion wherever possible. Because of the contexts (including, but not limited to, sources.list) where you can't use those numbers, and have to use codenames instead, that hasn't been helpful to me. The numbers also don't have any intuitive correlation with the names, so mapping from one to another requires looking them up in some appropriate document, which is inconvenient enough that in practice it mostly won't be done. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: where are the crontab files in Trixie?
On 2024-02-27 at 14:09, Gary Dale wrote: > On 2024-02-27 10:26, The Wanderer wrote: > >> On 2024-02-27 at 10:15, Gary Dale wrote: >> >>> Anyway, that got me down the rabbit hole to try to find where the >>> crontab file is. >>> >>>ls -l /root/cron* >>> ls: cannot access '/root/cron*': No such file or directory >>> >>> also >>> >>> # whereis crontab >>> crontab: /usr/bin/crontab /etc/crontab /usr/share/man/man1/crontab.1.gz >>> /usr/share/man/man5/crontab.5.gz >>> >>> so it's not in the location that you'd expect. >> >> I'm not sure whereis is suitable for finding things like this. As >> its man page states, it's for finding "the binary, source, and >> manual page files for a command" - not the data files which the >> command may work with. > > locate crontab also fails to find it, That would be because updatedb is configured to exclude /var/spool and everything underneath it. Look at /etc/updatedb.conf; you'll probably find that PRUNEPATHS is set to include /var/spool. (It is on my system, and I'm reasonably certain that it's by default.) > as does find / -name crontab Invoked how? In particular, as which user? Assuming that the crontab files are actually named literally 'crontab' with no extra characters (perhaps by being stored one per directory), my guess would be that this is because /var/spool/cron/crontabs is not world-executable, and therefore most users won't be able to list its contents. If you run that 'find' command as root, or as a user which is in the group that owns the directory, you may see that the files show up. (If they aren't literally named just 'crontab' verbatim, then you'd also need to specify wildcards etc. in the find arguments, in order for it to recognize them as being a valid match.) >>> Nor can I find it in /etc/. The various cron files there don't >>> contain the lines I;m looking for. >>> >>> Can anyone explain how Trixie is handling crontabs now? >> >> The first paragraph of crontab(1) states: >> >>>> Each user can have their own crontab, and though these are >>>> files in /var/spool/cron/crontabs,they are not intended to be >>>> edited directly. >> >> So, while I don't use per-user crontabs myself and so don't have >> experience with this personally, I would suggest looking in that >> directory - but not necessarily editing the files there, except >> via 'crontab -e' as you have already done. > > Thanks. I missed that when I was reading the comments. I need to > enlarge the text more, I guess. It took a bit of careful looking for me, too, even when I was fairly sure something like this would be in there. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: where are the crontab files in Trixie?
On 2024-02-27 at 10:15, Gary Dale wrote: > Anyway, that got me down the rabbit hole to try to find where the > crontab file is. > > ls -l /root/cron* > ls: cannot access '/root/cron*': No such file or directory > > also > > # whereis crontab > crontab: /usr/bin/crontab /etc/crontab /usr/share/man/man1/crontab.1.gz > /usr/share/man/man5/crontab.5.gz > > so it's not in the location that you'd expect. I'm not sure whereis is suitable for finding things like this. As its man page states, it's for finding "the binary, source, and manual page files for a command" - not the data files which the command may work with. > Nor can I find it in /etc/. The various cron files there don't > contain the lines I;m looking for. > Can anyone explain how Trixie is handling crontabs now? The first paragraph of crontab(1) states: >> Each user can have their own crontab, and though these are files in >> /var/spool/cron/crontabs,they are not intended to be edited >> directly. So, while I don't use per-user crontabs myself and so don't have experience with this personally, I would suggest looking in that directory - but not necessarily editing the files there, except via 'crontab -e' as you have already done. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Inclusive terminology (instead of master/slave) for network bonding/LACP
On 2024-02-24 at 08:42, Emanuel Berg wrote: > jeremy ardley wrote: > >>> But what about the black market? Or does in fact "block market" >>> work just fine? >> >> The term "black market" is from World War II - i.e. 1939-45. It has >> nothing to do with slaves. It means transactions in the dark, not >> visible, not official. > > I think the reason is black people shouldn't be associated with > everything negative that is black in language. The answer to that would then be to stop making such associations, on the basis that it was a misnomer to label those people as "black" (with whatever pre-existing connotations, negative or otherwise, that may have had) in the first place - not to require that everything negative that has that label be given a different label. That may seem (or even be) unrealistically facile, but that doesn't mean it isn't in some sense the correct resolution. It can hardly be much more unrealistic than getting everyone to change all existing negative-sense usage of "black". > It was a BLM thing, not sure if it matters the etymology of such > words. The etymology certainly *should* matter, insofar as that is the origin of the *meaning* of the word(s). -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Journald's qualities
On 2024-02-23 at 15:35, Stefan Monnier wrote: >>> but what are the advantages of journald's representation compared >>> to a naive one? >> >> in short: querability without text parsing. That's about it. > > They have to parse the binary format, so that's not in and of itself > an upside compared to parsing CSV. > > I've made my share of bad design decisions that don't pan out. But > there's always an upside to my decision (even when it turns out it > speeds up only those cases which can never occur, because of some > other aspect of the system). > > AFAICT the format is *not* just a plain sequence of log entries, so > there's some additional structure which is intended to speed up some > operations. > > IOW, even if contrived, there should be *some* use case where it > does better than CSV, no? I can think of two possibilities, just offhand, in no particular order: * No need to parse the timestamps, et cetera, and take the risk that someone put in one that's in a format you don't expect; the times are stored internally in a consistent guaranteed format, so you can just use internal reader functions (paired with, and updated alongside, the internal writer functions) and be done with it. * No need to worry about handling log entries that *contain* commas, or whatever other element was chosen as the separator. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: "I: update-initramfs is disabled (live system is running on read-only media)" ...
On 2024-02-16 at 14:44, Albretch Mueller wrote: > I've got a relatively old laptop with an ATI Radeon HD card, which > firmware I can't update. Wild pixelations happen even on relatively > simple pages not just videos. It seems to be a common problem. What I > have searched and found out is that I will have to un/repack initramfs > ..., but I haven't found a relatively safe, complete procedure. > > How can you update the initramfs on read-only media? At a guess: * Copy the read-only media to a writable location. This is "the image tree". * Extract the initramfs from the file which contains it, into an empty directory. This is "the extracted initramfs". * Modify the files in the extracted initramfs. The result is "the updated extracted initramfs". * Create a new initramfs whose contents are the updated extracted initramfs. Copy it into the image tree. The result is "the updated image tree". * Write the updated image tree to new read-only media. Depending on what form the media is, this may require other steps first; for example, if it's a CD or DVD, you will probably need to create an ISO using a tool like genisoimage or (I think) xorriso. Read-only media is by definition not update-able. You can only create new media, using a modified copy of the files from the read-only media. I have successfully built updated versions of live-boot CDs, with updated kernels and initrd environments and so forth, using this basic method. It has been a long time, but I can confirm that it works, if done correctly. Now, if what you want to know is how to extract the initramfs... that depends on how it's compressed, which may depend on what live-system boot media you're working with, but typically it will be a gzip-compressed cpio archive. In that case, working from memory based on the last time I was doing such a thing, what you'd need to do is something like: $ mkdir /tmp/extract $ cp /path/to/image/tree/initrd.gz /tmp/extract $ gunzip /tmp/extract/initrd.gz $ mkdir /tmp/extract/extracted-initramfs $ cd /tmp/extract/extracted-initramfs $ cpio -i < ../initrd And to create a new one (without overwriting anything created during the above), you'd do something like: $ mv /tmp/extract/initrd /tmp/extract/initrd.unmodified $ cd /tmp/extract/extracted-initramfs $ find . | cpio -o > ../initrd $ gzip -9 /tmp/extract/initrd $ mv /tmp/extract/initrd.gz /path/to/image/tree/initrd.gz *DO* *NOT* just take this as a recipe to follow. Read the documentation of the programs involved, look for examples online if that documentation doesn't make things clear in your mind, and use this as a *starting point* to figure out what the correct thing to do in your circumstance actually is. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Package Identification Assistance
On 2024-02-16 at 09:14, Greg Wooledge wrote: >>> On Thu, 15 Feb 2024 20:33:16 -0500 Neal Heinecke wrote: >>> >>>> I need to identify the package responsible for creating the >>>> software sources window. There is a minor bug/typo where the >>>> first tab reads "Ubuntu Software" > I would also point out that this is a Debian mailing list, not an > Ubuntu mailing list, and therefore the people here don't know > anything about Ubuntu systems (generally). > > Maybe this program is normal and common on Ubuntu. If that's the > case, then asking on an Ubuntu mailing list or web forum would > probably have got a useful reply immediately, whereas all *we* can do > is scratch our heads and toss out random guesses. I could be on the wrong track, but I parsed the original post as reporting that a program on Debian identifies itself as being connected to Ubuntu, and that this would constitute a bug, and as wanting to identify the package responsible for that program *so as to be able to report that bug so that it can be fixed*. If that's correct, then the original question was "how can I identify the package on my Debian system which contains the program which is misbehaving in this way?", which would seem to be perfectly fine as a question for debian-user. That said, I don't have any idea of suggestions to offer, without more information which the original poster has not provided. To start with, I'd want to know: what steps is it which cause the window which displays this improperly-titled tab to open? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-02-15 at 01:18, songbird wrote: > The Wanderer wrote: > >> TL;DR: It worked! I'm back up and running, with what appears to be >> all my data safely recovered from the failing storage stack! > > i'm glad you got it back up and running and i hope all your data is > intact. :) Thank you. It's quite a relief on my end as well. > which SSDs did you use? The model name/number isn't terribly meaningful-looking. I gave it in my reply to David, fairly deep in the wall of text. They're Intel 3.84Ti?B SSDs, reportedly intended for server or data-center use. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-11 at 15:25, Stefan Monnier wrote: >> manufacturers in different memory banks, but since it's always >> possible to power down, replace or just remove memory, and power up >> again, > > Hmm... "always"? What about long running computations like that > simulation (or LLM training) launched a month ago and that's expected > to finish in another month or so? > > Some mainframes have supported hot (un)plugging RAM modules as well > and I wouldn't be surprised if some x86 servers also support it > nowadays. I remember, in my previous job (back in the oughts, now), one occasion on which I was going around adding RAM to various desktop computers in the area under my purview, by adding more DIMMs to the open slots - and discovering, when I put the case back together on one of those computers and went to power it back on, that *it was already powered on and the system was still booted*. Surprisingly, none of the hardware showed any sign of damage, and the system recognized the RAM just fine after a reboot. But it was a bit of a jolt at the time to realize that I'd just done parts surgery, however mild, on a powered and running system. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-02-15 at 03:09, David Christensen wrote: > On 2/14/24 18:54, The Wanderer wrote: > >> TL;DR: It worked! I'm back up and running, with what appears to be >> all my data safely recovered from the failing storage stack! > > That is good to hear. :-) > >> On 2024-01-09 at 14:22, The Wanderer wrote: >> >>> On 2024-01-09 at 14:01, Michael Kjörling wrote: >>> >>>> On 9 Jan 2024 13:25 -0500, from wande...@fastmail.fm (The >>>> Wanderer): >> >>>>> I've ordered a 22TB external drive > > Make? Model? How it is interfaced to your computer? It's a WD Elements 20TB drive (I'm not sure where I got the 22 from); the back of the case has the part number WDBWLG0200HBK-X8 (or possibly -XB, the font is kind of ambiguous). The connection, per the packaging label, is USB-3. >> In the time since this, I continued mostly-normal but >> somewhat-curtailed use of the system, and saw few messages about >> these matters that did not arise from attempts to back up the data >> for later recovery purposes. > > Migrating large amounts of data from one storage configuration to > another storage configuration is non-trivial. Anticipating problems > and preparing for them ahead of time (e.g. backups) makes it even > less trivial. The last time I lost data was during a migration when > I had barely enough hardware. I made a conscious decision to always > have a surplus of hardware. The big change of plans in the middle of my month-plus process was the decision to replace the entire 8-drive array with a 6-drive array, and the reason for that was because the 8-drive array left me with no open SATA ports to be able to connect spare drives in order to do drive replacements without needing to rebuild the whole shaboozle. I don't currently have a surplus of hardware (see the $2200 it already cost me for the replacement drives I have), but I also haven't yet initiated a warranty claim on the 870 EVO drives, and it seems possible that that process might leave me with either replacement drives on that front or just plain money (even if from selling the replacement drives on e.g. eBay) with which to purchase spare-able hardware. >>> (For awareness: this is all a source of considerable >>> psychological stress to me, to an extent that is leaving me on >>> the edge of physically ill, and I am managing to remain on the >>> good side of that line only by minimizing my mental engagement >>> with the issue as much as possible. I am currently able to read >>> and respond to these mails without pressing that line, but that >>> may change at any moment, and if so I will stop replying without >>> notice until things change again.) >> >> This need to stop reading wound up happening almost immediately >> after I sent the message to which I am replying. > > I remember reading your comment and then noticing you went silent. I > apologize if I pushed your button. As far as I know you didn't. I don't think I even read any of the replies after sending that message, and if I did, I don't remember any of them having this type of impact; it was just the holistic stress of the entire situation. >> I now, however, have good news to report back: after more than a >> month, at least one change of plans, nearly $2200 in replacement >> hard drives, > > Ouch. Yeah. The cost factor is why I was originally planning to spread this out over time, buying two drives a month until I had enough to replace drives one at a time in the 8-drive array. I eventually decided that - especially with the rsnapshot tiered backups turning out not to be viable, because of the hardlinks thing - the risk factor of stretching things out further wasn't going to be worth the benefit. IIRC, the drives were actually $339 apiece, which would put the total price for six in the $2030-$2040 range; sales tax and shipping costs were what put it up to nearly $2200. > If you have a processor, memory, PCIe slot, and HBA to match those > SSD's, the performance of those SSD's should be very nice. The CPU is a Ryxen 5 5600X. The RAM is G-Skill DDR4 2666MHz, in two 32GB DIMMs. I don't know how to assess PCIe slots and HBA, but the motherboard is an Asus ROG Crosshair VIII Dark Hero, which I think was the top-of-the-line enthusiast motherboard (with the port set my criteria called for) the year I built this machine. I'm pretty sure my performance bottleneck for most things is the CPU (or the GPU, where that comes into play, which here it doesn't); storage-wise this seems so far to be at least as fast as what I had before, but it's hard to tell if it's faster. >> much nervous stress, several days of running data copies to and >> from a 20+-terabyte mechanical hard drive over USB, and a co
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-02-15 at 07:14, debian-u...@howorth.org.uk wrote: > The Wanderer wrote: > >> It turns out that there is a hard limit of 65000 hardlinks per >> on-disk file; > > That's a filesystem dependent value. That's the value for ext4. I think I recall reading that while I was flailing over this, yes. ext4 is what I use for daily-driver purposes these days; from the little I've looked into the matter, everything else seems to be either too complicated, or too non-robust, to be worth risking my live data on. > XFS has a much larger limit I believe. As well as some other helpful > properties for large filesystems. > > btrfs has different limits, depending on where the hardlinks are, > apparently. Some larger, some ridiculously smaller. So it might make sense to use one of those as the underpinning for whatever external system I wind up setting up for tiered backup, then. Though experimentation to determine the limits would be warranted. That's not immediately actionable, but it's good to have in the background as planning etc. takes place. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
TL;DR: It worked! I'm back up and running, with what appears to be all my data safely recovered from the failing storage stack! On 2024-01-09 at 14:22, The Wanderer wrote: > On 2024-01-09 at 14:01, Michael Kjörling wrote: > >> On 9 Jan 2024 13:25 -0500, from wande...@fastmail.fm (The >> Wanderer): >>> I've ordered a 22TB external drive for the purpose of creating >>> such a backup. Fingers crossed that things last long enough for >>> it to get here and get the backup created. >> >> I suggest selecting, installing and configuring (as much as >> possible) whatever software you will use to actually perform the >> backup while you wait for the drive to arrive. It might save you a >> little time later. Opinions differ but I like rsnapshot myself; >> it's really just a front-end for rsync, so the copy is simply >> files, making partial or full restoration easy without any special >> tools. > > My intention was to shut down everything that normally runs, log out > as the user who normally runs it, log in as root (whose home > directory, like the main installed system, is on a different RAID > array with different backing drives), and use rsync from that point. > My understanding is that in that arrangement, the only thing > accessing the RAID-6 array should be the rsync process itself. > > For additional clarity: the RAID-6 array is backing a pair of > logical volumes, which are backing the /home and /opt partitions. The > entire rest of the system is on a series of other logical volumes > which are backed by a RAID-1 array, which is based on entirely > different drives (different model, different form factor, different > capacity, I think even different connection technology) and which has > not seen any warnings arise. > >>> dmesg does have what appears to be an error entry for each of >>> the events reported in the alert mails, correlated with the >>> devices in question. I can provide a sample of one of those, if >>> desired. >> >> As long as the drive is being honest about failures and is >> reporting failures rapidly, the RAID array can do its work. What >> you absolutely don't want to see is I/O errors relating to the RAID >> array device (for example, with mdraid, /dev/md*), because that >> would presumably mean that the redundancy was insufficient to >> correct for the failure. If that happens, you are falling off a >> proverbial cliff. > > Yeah, *that* would be indicative of current catastrophic failure. I > have not seen any messages related to the RAID array itself. In the time since this, I continued mostly-normal but somewhat-curtailed use of the system, and saw few messages about these matters that did not arise from attempts to back up the data for later recovery purposes. > (For awareness: this is all a source of considerable psychological > stress to me, to an extent that is leaving me on the edge of > physically ill, and I am managing to remain on the good side of that > line only by minimizing my mental engagement with the issue as much > as possible. I am currently able to read and respond to these mails > without pressing that line, but that may change at any moment, and if > so I will stop replying without notice until things change again.) This need to stop reading wound up happening almost immediately after I sent the message to which I am replying. I now, however, have good news to report back: after more than a month, at least one change of plans, nearly $2200 in replacement hard drives, much nervous stress, several days of running data copies to and from a 20+-terabyte mechanical hard drive over USB, and a complete manual removal of my old 8-drive RAID-6 array and build of a new 6-drive RAID-6 array (and of the LVM structure on top of it), I now appear to have complete success. I am now running on a restored copy of the data on the affected partitions, taken from a nearly-fully-shut-down system state, which is sitting on a new RAID-6 array built on what I understand to be data-center-class SSDs (which should, therefore, be more suitable to the 24/7-uptime read-mostly workload I expect of my storage). The current filesystems involved are roughly the same size as the ones previously in use, but the underlying drives are nearly 2x the size; I decided to leave the extra capacity for later allocation via LVM, if and when I may need it. I did my initial data backup to the external drive, from a still-up-and-running system, via rsnapshot. Attempting to do a second rsnapshot, however, failed at the 'cp -al' stage with "too many hardlinks" errors. It turns out that there is a hard limit of 65000 hardlinks per on-disk file; I had so many files already hardlinked together on the source filesystem that trying to
Re: Can't list root directory
On 2024-01-29 at 11:42, Gary Dale wrote: > I'm running Debian/Trixie on an AMD64 workstation. I've lost the > ability to see the root directory even when I am logged in as root > (su -). > > This has been happening intermittently for several months. I > initially thought it might be related to failing NVME drive that was > part of a RAID1 array that is mounted as "/" but I replaced the > device and the problem is still happening. > > I had been able to fix it by booting to SystemRescue and running an > fsck on the device but it didn't work this time. The device checks > out OK (even when using fsck -/dev/mdx -f) but I still can't list the > root. "ls -l /" just hangs, as do any attempts to see the root > directory in a graphical file manager. In dolphin this means there is > nothing in the folders - and since that is the default starting point > I have to manually enter a folder name (e.g. /home/me) in the > location bar to be able to see anything - but even then the folders > panel remains empty. > > Even running commands like df -h hang because they can't access the > root folder. However the system is otherwise running normally. I'm not sure it'll help lead to anything, but out of curiosity and/or as a possible diagnostic: when the problem is manifesting, what happens if you run 'stat /'? Does it report data (similar to what you'd get from 'stat' on another directory), or does it hang, or give errors, or...? My thought is that this will give information about the filesystem object that is the root directory, without trying to also access information about the *contents* of that directory. If the one succeeds where the other fails, that might help narrow down where the actual issue is. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: apt full-upgrade failed at marco-common package
On 2024-01-30 at 07:19, Miroslav Skoric wrote: > Hi, > > I [partially] upgraded buster to bullseye according to official "Release > Notes for Debian 11 (bullseye), 32-bit PC" (October 4, 2023). I did it > in two sessions as suggested: > > "4.4.4 Minimal system upgrade" (# apt upgrade --without-new-pkgs). That > part performed without any issue, and cat /etc/debian_version reported > 11.8 (previously it was 10.x). > > "4.4.5 Upgrading the system" (# apt full-upgrade) ran also fine until > some 20% or so, and then failed when handled marco-common package. Here > are the few last lines of that session: > > ... > Preparing to unpack .../6-mate-settings-daemon-common_1.24.1-1_all.deb ... > Unpacking mate-settings-daemon-common (1.24.1-1) over (1.20.4-1) ... > Preparing to unpack .../7-marco_1.24.1-3_i386.deb ... > Unpacking marco (1.24.1-3) over (1.20.3-1) ... > Preparing to unpack .../8-marco-common_1.24.1-3_all.deb ... > Unpacking marco-common (1.24.1-3) over (1.20.3-1) ... > .[1mdpkg:.[0m error processing archive > /tmp/apt-dpkg-install-S65GMD/8-marco-common_1.24.1-3_all.deb (--unpack): > trying to overwrite > '/usr/share/themes/Gorilla/metacity-1/metacity-theme-1.xml', which is > also in package gnome-themes-more 0.9.0.deb0.8 Where do you get 'gnome-themes-more' from? At least as far as I can tell without more digging, it isn't in current stable or testing. It *is* available on archive.debian.org and snapshot.debian.org, with that version number, but based on the timestamps it doesn't seem to have been updated since 2010. > Errors were encountered while processing: > /tmp/apt-dpkg-install-S65GMD/8-marco-common_1.24.1-3_all.deb > > > A repeated # apt full-upgrade returned a list of unmet dependencies, > including this one: > > marco : Depends: marco-common (= 1.24.1-3) but 1.20.3-1 is installed > > At the end of the list it suggested: Try 'apt --fix-broken install' with > no packages (or specify a solution). I tried it and it seemed as if it > tried to process again the above lines (unpacking, preparing), to no avail. > > What can I try to resolve that? After system reboot, I am able to reach > the rescue mode as root and type commands. (Green 'OK' follow all parts > of boot. GUI, startx fail. Shutdown, poweroff run properly.) My first default would be to remove gnome-themes-more (possibly with apt, possibly directly with dpkg), then try the '--fix-broken' step again. Assuming that works, I'd then follow it up by repeating the full-upgrade step just to make sure, and then after that - if I really wanted gnome-themes-more - try to reinstall it (preferably using an updated package, if you can get your hands on one). I suspect that files have been moved between packages since that version was released, and (some of) the files which were previously in gnome-themes-more are now in marco-common. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: How to prevent rtkit from giving firefox higher priority?
On 2024-01-17 at 09:02, hw wrote: > On Wed, 2024-01-17 at 07:26 -0500, Greg Wooledge wrote: > >> On Wed, Jan 17, 2024 at 11:19:50AM +0100, hw wrote: >> > systemctl --user show -p InvocationID at-spi-dbus-bus.service >> > InvocationID=4bd113a0ec4c4f1eab6c51da8a43c1af >> > Invalid unit name "InvocationID=4bd113a0ec4c4f1eab6c51da8a43c1af" escaped >> > as "InvocationID\x3d4bd113a0ec4c4f1eab6c51da8a43c1af" (maybe you should >> > use systemd-escape?). >> > InvocationID=b6e84c2dd18b4d9f84436580113abaca >> > >> > InvocationID= >> >> What were you trying to do? You took my command and mangled it. You >> appended the *output* of my command as an *argument* to your command, >> substituting my 128-bit InvocationID with one of your own. Why? > > I copied your command and replaced the UUID with one that shows up in > /run/user/1000/systemd/units/ as a link target since it seems unlikely > that the same UUIDs you have are being used here.. At least that was > my intention. > > Maybe your command was supposed to be 'systemctl --user show -p > InvocationID at-spi-dbus-bus.service'? Not just "supposed to be" - I'm essentially certain that it *was* that. What I think happened is that you saw the command, and its output on the next line, and mistakenly thought that this was a single longer command that had been line-wrapped. > That shows only > > > InvocationID=b6e84c2dd18b4d9f84436580113abaca > > > which doesn't tell me anything. If I'm not mistaken, it shows the same value as is the target of the symlink, which tells you that the target of the symlink is the InvocationID value. (I'd guess that the command is getting it from that same symlink.) >> > Neither the user, nor root gets anything from this. What is it >> > supposed to show? >> >> You got the InvocationID of the at-spi-dbus-bus.service unit. You >> also got an error message because of the mangled argument you passed, >> and an extra blank InvocationID= line as output from that same mangled >> argument, because it wasn't a running unit's name. >> >> When I ran *my* command, I was simply demonstrating that the "systemctl" >> command, when asked for the InvocationID of a unit, gives the same >> 128-bit number that you can see with ls -l. >> >> That's all. Nothing more complicated than that. > > How would that be useful? As a way of looking up the InvocationID of the "service" in question. >> THE 128-BIT HEX NUMBER IS THE CONTENT. IT IS THE DATA. IT IS WHAT YOU >> SEEM TO BE LOOKING FOR. THAT'S ALL THERE IS. THERE IS NO ADDITIONAL >> PAYLOAD TO BE FOUND. >> >> THE SYMBOLIC LINKS ARE *SUPPOSED* TO BE DANGLING. THEY ARE NOT MEANT >> TO BE catTED. > > If that is so, what is the purpose of useless directory entries? My guess is: so that they can get the data directly in a variable by a call to stat() or similar, rather than having to read and parse (and validate against possible malicious replacement) the contents of a file. I wouldn't consider that to be sufficient benefit to justify abusing the semantics of symbolic links, but it's long since clear that the freedesktop.org people don't use the same criteria in assessing these things as I would, so it's no surprise that they might have done it anyway. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09 at 14:01, Michael Kjörling wrote: > On 9 Jan 2024 13:25 -0500, from wande...@fastmail.fm (The Wanderer): > >>>> Within the past few weeks, I got root-mail notifications from >>>> smartd that the ATA error count on two of the drives had >>>> increased - one from 0 to a fairly low value (I think between >>>> 10 and 20), the other from 0 to 1. I figured this was nothing >>>> to worry about - because of the relatively low values, because >>>> the other drives had not shown any such thing, and because of >>>> the expected stability and lifetime of good-quality SSDs. >>>> >>>> On Sunday (two days ago), I got root-mail notifications from >>>> smartd about *all* of the drives in the array. This time, the >>>> total error counts had gone up to values in the multiple >>>> hundreds per drive. Since then (yesterday), I've also gotten >>>> further notification mails about at least one of the drives >>>> increasing further. So far today I have not gotten any such >>>> notifications. >> >> Do you read the provided excerpt from the SMART data as indicating >> that there are hundreds of bad blocks, or that they are rising >> rapidly? > > No; that was your claim, in the paragraph about Sunday's events. That paragraph was about the Uncorrectable_Error_Cnt value, which I do not understand to directly reflect a count of bad blocks. That's why I wanted to clarify; if you *do* understand that to directly reflect bad blocks, I'd like to understand your thinking in arriving at that understanding, and if alternately you were reaching that conclusion from other sources, I'd like to know how and from what, because it would be something I've missed. >> The Runtime_Bad_Block count for that drive is nonzero, but it is >> only 31. >> >> What's high and seems as if it may be rising is the >> Uncorrectable_Error_Cnt value (attribute 187) - which I understand >> to represent *incidents* in which the drive attempted to read a >> sector or block and was unable to do so. > > The drive may be performing internal housekeeping and in doing so > try to read those blocks, or something about your RAID array setup > may be doing so. > > Exactly what are you using for RAID-6? mdraid? An off-board hardware > RAID HBA? Motherboard RAID? Or something else? What you say suggests > mdraid or something similar. mdraid, yes. >> I've ordered a 22TB external drive for the purpose of creating such >> a backup. Fingers crossed that things last long enough for it to >> get here and get the backup created. > > I suggest selecting, installing and configuring (as much as > possible) whatever software you will use to actually perform the > backup while you wait for the drive to arrive. It might save you a > little time later. Opinions differ but I like rsnapshot myself; it's > really just a front-end for rsync, so the copy is simply files, > making partial or full restoration easy without any special tools. My intention was to shut down everything that normally runs, log out as the user who normally runs it, log in as root (whose home directory, like the main installed system, is on a different RAID array with different backing drives), and use rsync from that point. My understanding is that in that arrangement, the only thing accessing the RAID-6 array should be the rsync process itself. For additional clarity: the RAID-6 array is backing a pair of logical volumes, which are backing the /home and /opt partitions. The entire rest of the system is on a series of other logical volumes which are backed by a RAID-1 array, which is based on entirely different drives (different model, different form factor, different capacity, I think even different connection technology) and which has not seen any warnings arise. >> dmesg does have what appears to be an error entry for each of the >> events reported in the alert mails, correlated with the devices in >> question. I can provide a sample of one of those, if desired. > > As long as the drive is being honest about failures and is reporting > failures rapidly, the RAID array can do its work. What you > absolutely don't want to see is I/O errors relating to the RAID array > device (for example, with mdraid, /dev/md*), because that would > presumably mean that the redundancy was insufficient to correct for > the failure. If that happens, you are falling off a proverbial > cliff. Yeah, *that* would be indicative of current catastrophic failure. I have not seen any messages related to the RAID array itself. (For awareness: this is all a source of considerable psychological stress to me, to an extent that is leaving me on the edge of
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09 at 11:21, Michael Kjörling wrote: > On 9 Jan 2024 08:11 -0500, from wande...@fastmail.fm (The Wanderer): > >> Within the past few weeks, I got root-mail notifications from >> smartd that the ATA error count on two of the drives had increased >> - one from 0 to a fairly low value (I think between 10 and 20), the >> other from 0 to 1. I figured this was nothing to worry about - >> because of the relatively low values, because the other drives had >> not shown any such thing, and because of the expected stability and >> lifetime of good-quality SSDs. >> >> >> On Sunday (two days ago), I got root-mail notifications from >> smartd about *all* of the drives in the array. This time, the total >> error counts had gone up to values in the multiple hundreds per >> drive. Since then (yesterday), I've also gotten further >> notification mails about at least one of the drives increasing >> further. So far today I have not gotten any such notifications. > > A single or a few bad blocks is nothing to be overly concerned > about. I had an Intel SSD which lived a long, healthy, happy life > with one bad sector and never gave any signs of further problems. > > Hundreds of bad blocks per drive is certainly cause for concern. > > More worrying is a _significant increase in the rate of increase_ of > the bad blocks count. That suggests that the drive is suffering from > some underlying problem. Do you read the provided excerpt from the SMART data as indicating that there are hundreds of bad blocks, or that they are rising rapidly? The Runtime_Bad_Block count for that drive is nonzero, but it is only 31. What's high and seems as if it may be rising is the Uncorrectable_Error_Cnt value (attribute 187) - which I understand to represent *incidents* in which the drive attempted to read a sector or block and was unable to do so. >> So... as the Subject asks, should I be worried? How do I interpret >> these results, and at what point do they start to reflect something >> to take action over? If there is not reason to be worried, what >> *do* these alerts indicate, and at what point *should* I start to >> be worried about them? > > At an absolute minimum, were it me, I would refresh my backups. As > 8-wide RAID-6 of 2TB drives nets you about 12 TB of storage, I'd say > get yourself a ~16 TB external rotational HDD and set up to backup > onto it. You should have backups anyway; there's no time like the > present to get started. I've ordered a 22TB external drive for the purpose of creating such a backup. Fingers crossed that things last long enough for it to get here and get the backup created. > You are admittedly in a much better position than many; if the > errors are randomly located, odds are that you have sufficient > redundancy to manage within the storage array. That's what I'm relying on. > The good part is if you look at SMART attributes 5 and 179; taken in > combination, I take them as indication that all (31) reallocated > sectors have been reallocated into the spare sectors pool, and this > represents approximately 2% of the spare sectors pool. The fact that this is the same value as the Runtime_Bad_Block count (attribute 183) is something I'd noticed before sending that mail, and is probably not a coincidence. > Absolutely do keep an eye on attribute 179. If the spare sectors > pool start to fill up, the drive won't be able to reallocate any > further sectors, and your RAID array won't do you much good. > > I would also keep an eye out for I/O errors in the kernel log, but > be mindful of which devices they are coming from. dmesg does have what appears to be an error entry for each of the events reported in the alert mails, correlated with the devices in question. I can provide a sample of one of those, if desired. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09 at 11:12, Curt wrote: > On 2024-01-09, The Wanderer wrote: > >> My default plan is to identify an appropriate model and buy a pair >> of replacement drives, but not install them yet; buy another two >> drives every six months, until I have a full replacement set; and >> start failing drives out of the RAID array and installing >> replacements as soon as one either fails, or looks like it's >> imminently about to fail. But if the mass notification mails >> indicate that all eight are nearing failure, that might not be >> enough - and if they don't indicate any likelihood of failure this >> year, then buying replacement drives yet might be premature. > > Isn't it advised not to use the drives in this case, or to unmount > them, or to avoid all reads and writes (or however it should be > termed, as we all agree your symptoms mean trouble) in order to avoid > exacerabating the upcoming failure? Or does this go without saying? It probably is, but I don't have an alternative, since this is my daily-driver computer and I can't afford to go without one in the interim. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2024-01-09 at 09:38, Dan Ritter wrote: > The Wanderer wrote: > >> So... as the Subject asks, should I be worried? How do I interpret >> these results, and at what point do they start to reflect something >> to take action over? If there is not reason to be worried, what >> *do* these alerts indicate, and at what point *should* I start to >> be worried about them? >> >> I already *am* worried, to the point of having heartburn and >> difficulty sleeping over the possibility of data loss (there's >> enough on here that external backup would be somewhat difficult to >> arrange), but I'm not sure whether or not that is warranted. > > YES. Backup ASAP. > > 2TB and 4TB Samsung 870 EVO disks produced before November 2022 have > this as a known failure mode. AARGH. I spent (what I'm now fairly sure was) *thousands* on these things, after comparing a fair few drive models in reviews, and this is the first I've heard that there was any issue. Thank you for pointing it out. I have now done a bit of specific looking regarding this model, and found a thread discussing it which started in January 2022 and *is still going today*. I have now ordered a high-capacity external hard drive to back up the data (delivery date is this coming Monday), and two Intel enterprise-class drives to start having a reserve on hand for the expected failure. I don't really have the funds right now to buy replacements for everything immediately, at least not without carrying a lot more of a credit-card balance than I want to, but I want to at least get started. >> Model Family: Samsung based SSDs >> Device Model: Samsung SSD 870 EVO 2TB >> Serial Number:S620NJ0R410888A > > These may or may not be under warranty, depending on when you > purchased them and from whom. Assume Samsung will take a long time, > no matter what. IIRC, I bought them via Newegg, in early-to-maybe-mid 2021. (The alternative would be Amazon, but in this case I don't think that's how it happened.) I would be surprised if there were warranty coverage at this point, but might look a bit deeper; even if there is coverage, however, it's not worth waiting (and risking data loss) for the process to complete. This is *not* a stress I need right now... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
SMART Uncorrectable_Error_Cnt rising - should I be worried?
If there is not reason to be worried, what *do* these alerts indicate, and at what point *should* I start to be worried about them? I already *am* worried, to the point of having heartburn and difficulty sleeping over the possibility of data loss (there's enough on here that external backup would be somewhat difficult to arrange), but I'm not sure whether or not that is warranted. My default plan is to identify an appropriate model and buy a pair of replacement drives, but not install them yet; buy another two drives every six months, until I have a full replacement set; and start failing drives out of the RAID array and installing replacements as soon as one either fails, or looks like it's imminently about to fail. But if the mass notification mails indicate that all eight are nearing failure, that might not be enough - and if they don't indicate any likelihood of failure this year, then buying replacement drives yet might be premature. What drives I choose to buy as replacement would also be influenced by how likely it is that this indicates impending failure. If it doesn't, then drives similar to what I already have would probably still be appropriate; if it does, then I'm going to want to go up-market and buy long-endurance drives intended for high uptime - i.e., data-center storage drives, which are likely to be more expensive. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw Model Family: Samsung based SSDs Device Model: Samsung SSD 870 EVO 2TB Serial Number:S620NJ0R410888A LU WWN Device Id: 5 002538 f31440901 Firmware Version: SVT01B6Q User Capacity:2,000,398,934,016 bytes [2.00 TB] Sector Size: 512 bytes logical/physical Rotation Rate:Solid State Device Form Factor: 2.5 inches TRIM Command: Available, deterministic, zeroed Device is:In smartctl database 7.3/5319 ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5 SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is:Tue Jan 9 07:32:13 2024 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 098 098 010Pre-fail Always - 31 9 Power_On_Hours 0x0032 095 095 000Old_age Always - 22286 12 Power_Cycle_Count 0x0032 099 099 000Old_age Always - 29 177 Wear_Leveling_Count 0x0013 099 099 000Pre-fail Always - 11 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 098 098 010Pre-fail Always - 31 181 Program_Fail_Cnt_Total 0x0032 100 100 010Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010Old_age Always - 0 183 Runtime_Bad_Block 0x0013 098 098 010Pre-fail Always - 31 187 Uncorrectable_Error_Cnt 0x0032 099 099 000Old_age Always - 598 190 Airflow_Temperature_Cel 0x0032 069 050 000Old_age Always - 31 195 ECC_Error_Rate 0x001a 199 199 000Old_age Always - 598 199 CRC_Error_Count 0x003e 100 100 000Old_age Always - 0 235 POR_Recovery_Count 0x0012 099 099 000Old_age Always - 21 241 Total_LBAs_Written 0x0032 099 099 000Old_age Always - 6950839497 signature.asc Description: OpenPGP digital signature
VAX emulation/simulation (was Re: systemd-timesyncd)
On 2024-01-07 at 19:20, Nicholas Geovanis wrote: > On Sun, Jan 7, 2024, 4:51 PM Charles Curley > wrote: > >> On Sun, 7 Jan 2024 20:36:12 + >> >> "Andrew M.A. Cater" wrote: >>> Gene - no partisan opinions, please, as per Code of Conduct? >> >> Oh, come on! Just because Gene doesn't like certain ancient Digital >> Equipment products…? >> > > Come on There has to be a linux-based VAX simulator somewhere out there > for Gene :-D > So he can practice getting VAXed... :-D > said the man who used to use LSI-11's :-D $ apt-cache show simh Package: simh [...] Description-en: Emulators for 33 different computers This is the SIMH set of emulators for 33 different computers: [...] DEC VAX (but cannot include the microcode due to copyright) No idea whether it'd be enough, but if anyone does actually want to pursue the idea, it might be worth looking at. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: kbrequest as in older /etc/inittab
(As is sometimes usual, I may well regret this.) On 2024-01-05 at 07:30, Greg Wooledge wrote: > On Thu, Jan 04, 2024 at 09:58:38PM -0600, Mike McClain wrote: > >> I don't think I can state any more clearly what I'm trying to do than >> 'to tie a call to openvt to Alt Up'. I'm assuming you don't know how >> to do that either. > > And ... what does THAT do? > > NAME >openvt - start a program on a new virtual terminal (VT). > > What program are you trying to start in the new VT? > >> You're quite right you can increase the number of gettys >> and you can log into every one of them before you can use them. > > How does that FAIL to meet your desired state? What do you want to do, > that this doesn't allow? > > Are you trying to "login" to a bunch of VTs as an unprivileged user > without actually logging in? Simply for convenience? (If so, why > can't you just SAY this so we know?) I often find that it is useful to consider any given proposed course of action in terms of three questions: What goal are you trying to accomplish? Why do you consider that goal to be worth accomplishing? How do you propose to accomplish that goal? The "how" of one goal can also be the "what" of another, and the "what" of one goal can also be the "why" of another. Here, the statement "tie a call to openvt to Alt+Up" is presented as the "what", but we don't know the "why". It could either be because you want to do this as a means to some other end, or because you want to do it *for its own sake* - e.g., as Greg puts it, "simply for convenience". If you want to do this for its own sake - if there is no higher "what" behind this, if this is the end of the goal chain - then as Greg says, it would be helpful for us to *know* that, because it will inform the possible answers. Stating the "why" explicitly would clarify that. On the other hand, if you want to do this as a means to accomplish some other end - if the "what" of this goal is also the "how" of some other goal - then in order to give useful answers, we will need to also know at least the "what" of that other goal, and possibly also its "why". (And, yes, that *can* apply recursively - although I would not expect it to do so here.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Heinlein and requirements (was Re: how to clone apt repository to newest only?)
On 2023-12-26 at 17:33, Andrew M.A. Cater wrote: > On Tue, Dec 26, 2023 at 04:49:13PM -0500, Roy J. Tellason, Sr. wrote: >> -- >> Member of the toughest, meanest, deadliest, most unrelenting -- and >> ablest -- form of life in this section of space, a critter that can >> be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" >> - > > Sounds like a project manager imposing random requirements :) You want to talk about random (or not so much) requirements found in Heinlein? >>> A human being should be able to change a diaper, plan an >>> invasion, butcher a hog, conn a ship, design a building, write a >>> sonnet, balance accounts, build a wall, set a bone, comfort the >>> dying, take orders, give orders, cooperate, act alone, solve >>> equations, analyze a new problem, pitch manure, program a >>> computer, cook a tasty meal, fight efficiently, die gallantly. >>> Specialization is for insects. I can probably do... somewhere in the range from four to ten of those, depending on one's definitions. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: wireless broadband providers exist
On 2023-12-20 at 19:39, Felix Miata wrote: > Pocket composed on 2023-12-20 17:55 (UTC-0500): > >> Actually I can not change as the ISP has exclusive rights to the high >> speed internet in the area I reside in. >> >> No other providers are allowed. > > That could be a historical concept, depending exactly on where you live. Some > of > us mericans who formerly had no access to real broadband except via > prohibitively > expensive, high latency satellite dish now have broadband provided > wirelessly. All > the big cablecos have been slowly rolling it out. The areas covered are > limited, > with limited overlap among providers. The targets so far have been mostly > areas > unserved by traditional cable, but there is overlap. Maybe you should check > with > T-Mobile: > https://www.allconnect.com/local/oh/columbus It is my understanding that there are (or at least have been, and I know of no reason for this to have changed) some apartment buildings, et cetera, in which there is a provision of the tenancy agreement (or whatever else applies) requiring that Internet service be exclusively through the provider chosen by the management of the apartment building. (The question of motivations for doing this, on the part of both the management and the provider, I leave un-discussed for at least the time being.) If that is correct, and if Pocket resides in such an environment, then it is possible that even if wireless "high-speed" Internet access could in a technical sense work in that area it might be prohibited in a contractual sense. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: how to firefox settings
On 2023-12-06 at 13:07, debian-u...@howorth.org.uk wrote: > fxkl4...@protonmail.com wrote: > >> on a page in firefox use tools -> page info -> permissions i notice >> override keyboard shortcuts is set to allow where can i change the >> defaults for this > > Defaults are built-in; you can't change them (except by modifying > the source and recompiling). > > You can turn off the Use defaults button and then change Allow or > Block as you wish. That's what the popup allows. I parsed the question as asking: "how can I configure things so that on a new profile for a new user, this comes up by default with a different value?". Depending on the details, that might be something that could be achieved via Firefox policy templates; I haven't looked at trying to do this by that mechanism, but it's the main thing that could potentially do it AFAIK, short of (as you say) modifying the source and recompiling. I don't have the link for the policy-templates site handy, but it should be easily findable by searching for those terms. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Request advice on Optimal Combo-usage of Gmail and Mailman, as mentioned in Msg-Id. "2023/11/msg00443"
On 2023-11-13 at 08:57, Eduardo M KALINOWSKI wrote:
> On 13/11/2023 09:31, Brad Rogers wrote:
>
>> On Mon, 13 Nov 2023 12:04:47 + Andy Smith
>> wrote:
>>
>> Hello Andy,
>>
>> {gmail web interface}
>>> that people put up with that.
>>
>> If they've always used google (and let's face it, there are plenty
>> of people that fall in to that category), then they have no
>> experience of anything else and quite possibly know no better.
>
> It's not only google, I'd say it's the norm, except for "advanced"
> users that use good MUA.
>
> And those are getting rare, I can't find a nice MUA for Android with
> proper threading.
If you ever do find one, please let me know. The lack of such a thing is
the primary reason why I don't do E-mail on Android *at all*.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: PATH question
On 2023-11-11 at 19:09, Greg Wooledge wrote: > On Sat, Nov 11, 2023 at 10:17:09PM +, David wrote: > >> Looking for an authoritative source of information to show you, >> I found only this: >> >> https://wiki.debian.org/DebianPackageManagement#Installing_and_removing_packages >> which says: >> You can also install a .deb file with: >> # apt install >> >> My understanding is that the must look like a pathname. >> So, to install 'debfile.deb' in the current directory, it should look like >> apt install ./debfile.deb >> >> Maybe someone else knows where the authoritative documentation >> of this capability can be read, if there is any. > > I think you've found it. It's not in ANY man page that I'm aware of. My reflexive reaction was "that sounds like something that warrants a wishlist-level bug report". Then I went looking, and I found a *normal*-level bug report that seems to cover the matter: https://bugs.debian.org/874763 And that bug report is from 2017, and has no replies. Unless someone is interested enough to write up a patch for apt.8 and send it to that bug report, I suspect that this will go unaddressed for a while longer. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: locate question
On 2023-11-07 at 11:32, gene heskett wrote: > Greetings all; > I dunno if I've forgot how to use it, or it broken by the same bug that > killing me with the lagging access to my home raid10. > > Fact: there are probably over 100 files in my /home/gene directory and > all its subs with assorted names ending in ".scad", made by OpenSCAD > Fact: I just ran "sudo updatedb" and generated a new date just now, > /var/cache/locate/locatedb.n > so that s/b uptodate. > Al of those files should be spit out by: > "locate *.scad" issued from an xfce terminal > but I get: > gene@coyote:~$ locate *.scad > /home/gene/vac_ctrl_box.scad > /home/gene/xhome_cable.scad Try instead: $ locate '*.scad' That should prevent the shell from expanding the wildcard before running the command. > Acc an ls -R|wc -l there are > 433179 > files in my /home/gene directory > > so locate isn't working as I think it should. > try find but it finds the whole my whole local net: > gene@coyote:~$ find .scad . |wc -l > find: ‘.scad’: No such file or directory > 1176532 Try $ find . -name '*.scad' > What am I doing wrong? For locate, you're not quoting the arguments properly. For find, you're also putting the arguments in the wrong order. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: How to get VMware Player going on Debian 12 bookworm
On 2023-11-06 at 07:50, Marco M. wrote: > Am 06.11.2023 um 06:52:39 Uhr schrieb Timothy M Butterworth: > >> VirtualBox is not available in any Debian Repo. > > It is available in sid, but not in stable. And the reason it isn't available in testing is that there's no viable way to provide security support for it in stable, and testing is supposed to only contain things that are candidates to become part of the next stable release. Once upon a time it was made available in each new testing and then removed before the stable release (and that's how I was running it, for a fairly long while), but I remember a discussion which led to the decision that that was not an appropriate practice given relevant policy. I don't remember with confidence offhand exactly *why* it was decided that it isn't viable to provide security support for VirtualBox in stable. I remember it had something to do with how upstream provides patches for security fixes, but I don't remember whether it was "upstream doesn't provide split-out patches per fix, but only one massive patch when they make a new VirtualBox release" or something more to the effect of "the license upstream releases its code under does not permit taking changes out separately like that". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Changing host name and domain name on Debian; was: Domain nametouse on home networks
On 2023-10-30 at 23:11, Max Nikulin wrote: > On 30/10/2023 00:00, gene heskett wrote: > >> Somebody who /can/ report it. I changed ISP's over a decade back, >> so I am not me to bugzilla, and because I am known also by name, I >> can't re-register. I can't even get a pw reset cuz it (I'm guessing >> here) is sending it to my earlier ISP's > > Sorry, it is not clear what particular bugzilla instance you are > writing about. You are sending e-mails and you should be able to > register a new account. Do you mean that you have managed to upset > developers to the degree when they decide to ban your active mail > address? I parsed it as something like "I can't register an account that has the same name (in whatever sense matters to me) as the one I had before, because that account already exists, and I can't recover that account, because it's trying to recover via an E-mail address I no longer have access to.". The question of in what sense the account has the "same name" is undetermined, but the existence of such an additional constraint is the only way I can see to parse the given scenario so that it makes sense. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Which Virtual Manager? Was: EASY way to install packages from trixie/sid to stable?
On 2023-10-28 at 00:25, Max Nikulin wrote: > On 28/10/2023 02:02, The Wanderer wrote: > >> for the case of hierarchical snapshots > > qemu-img(1) allows to create snapshots of disk images that are stored > in the same file. In addition the "create" command has the "-b > BACKING_FILE" option Does virt-manager expose this feature via a convenient create-a-new-snapshot GUI, showing the tree of which snapshots descend from what? I believe I was under the impression that, for the case of qemu, no such thing was available. (I note, again, that it's been a long time since I tried this; I have spent the past couple of years, at least, attempting with various degrees of desperation to avoid more stress than I can handle, and after my last try with virt-manager hit that wall this conversation is the first time I've been able to handle any kind of try-it-again.) >> If the option BACKING_FILE is specified, then the image will record >> only the differences from BACKING_FILE. > > Is it something close to "hierarchical snapshots"? If one snapshot can descend from another, and you can delete any snapshot (again, from that GUI) and have any references to it in other snapshots automagically cleaned up to point to any relevant new parent (such that the data seen through those other snapshots is still the same as before the deletion), then probably. It sounds like it might be worth my giving this another try, with qemu as a backend, and seeing if I get any better results. Not sure exactly when I may do that - I'm dealing with major stress from another source right now, and would probably have difficulty handling it if the attempt failed - but the idea is at least on my radar. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Domain name to use on home networks
On 2023-10-27 at 14:57, John Hasler wrote: > I wrote: > Greg writes: >> My Debian 12 system does not have an /etc/init.d/hostname.sh file, >> or anything else that's close to it. > > My desktop, which has been upgraded many times, does have > /etc/init.d/hostname.sh. However, a recently installed Bookworm does > not. Mine does: $ dlocate /etc/init.d/hostname.sh initscripts: /etc/init.d/hostname.sh $ apt-file search /etc/init.d/hostname.sh initscripts: /etc/init.d/hostname.sh At least in current testing+stable, it's contained exclusively in the 'initscripts' package. My guess is that a machine running systemd will not include that package, and therefore will not have this script. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Which Virtual Manager? Was: EASY way to install packages from trixie/sid to stable?
On 2023-10-27 at 10:46, Minecraftchest1 wrote: > With Virt-Manager, you should have the option to choose an existing > disk image. That only helps if you've already created a disk image, which will not be the case when creating a new VM from scratch. Having to resort to the command line (or to other tools) to create the initial disk image - even if, potentially, just creating an empty file (or a file of specified size, filled with zeroes) would work - is not as friendly or as straightforward a workflow as being able to do it from the GUI. > In that dialog, you can create an image in any of the pools (you can > also add pools in that dialog), and that will let you change the file > name and disk size. Hold up. Where do "pools" (which I'm guessing is short for "storage pools") come into things? The other virtualization solutions I've seen and worked with (short of full-system-level things, such as I understand VMWare ESXi to be) don't require being aware of or handling storage pools; they work with disk image files (or, for the case of hierarchical snapshots, cascading stacks thereof) directly, and do not require those files to be part of any "storage pool" in any way that the user needs to be aware of. If you're starting with the assumption that "storage pools" will - much less need to - be involved somewhere, you're already not matching the convenience etc. of the workflow I know from those other tools. Just offhand, I would expect that a "storage pools" paradigm would block off some of the convenient things that can be done in that other workflow, such as being able to move or copy a virtual machine by moving or copying the directory that its files (disk images, configuration files, et cetera) are stored in - because you'd also have to fiddle with whatever it is that defines the "storage pool" that those files are part of, and that definition would presumably be outside of the directory that defines the virtual machine. > I am not ay my laptop currently, but I can take and share some > screenshots later today. Regardless of the above, that might be useful. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Which Virtual Manager? Was: EASY way to install packages from trixie/sid to stable?
On 2023-10-26 at 15:28, Andrew M.A. Cater wrote: > Apt-get install virt-manager will pull in all the associated > qemu/KVM packages you might need. It should be at least as > straightforward to use as Virtualbox. I've seen people state or suggest multiple times that virt-manager should be, as you say, as straightforward to use as VirtualBox, and that was what I expected to find when I tried to use it myself - but even once I got around the issues that arose from my not using systemd et cetera and could actually use the program, it is not what I actually found. (I very much hope that what I am about to describe is wrong, and that people will explain how/why it's wrong, such that I can get out of the situation described and into a state where I can actually use virt-manager in a way that I could find useful. It is not my intention to spread FUD or falsehoods, even if some of the below may look like it would fall within those categories.) From what I recall from having used VirtualBox in the past, its workflow is fairly similar to what I see in using VMWare Workstation in a (work-related) Windows environment. When you create a new VM, it prompts you for where the VM's files should be stored, and then for details about the VM's configuration (disk sizes, hardware devices, et cetera), and optionally lets you specify what will be done to install the OS that will run in the VM - and then with that done, the VM is ready, and you can boot it up or create a snapshot (using a graphical snapshot-management interface) or make further configuration edits or do whatever else you will with it. With virt-manager, from what I recall (it has been a while since I last tried), the workflow was quite different. IIRC, I didn't even try using qemu as a backend, because AFAIK it doesn't support hierarchical VM snapshots and that's a feature I very much expect to rely on; instead I think I went with KVM. With that backend, AFAIR I didn't even get prompted for where the VM's file should be stored; instead, the location where the system stores files appears to be defined in a system-wide config file, and to not be modifiable on a per-VM basis (except relative to that system-wide root). That's a problem, because when I partitioned this system I expected to be able to store VM files in the same massive data partition as I allocated for other large data; the default system-wide location doesn't have the space to do much with. It also doesn't work when the system may have multiple users who may want to manage VMs separately from one another (though, fortunately, this is more an abstract concern rather than one that affects me in practice). With VMWare Workstation and what I think I I recall from VirtualBox, once a VM is created, the resulting files are owned by the user who ran the program. With what I recall from when I tried virt-manager, even if I redirected the file storage location to be under the larger data partition, the files were owned by another user, related to libvirt. That's undesirable when trying to store VM files per-user in a per-user location, since the user won't be able to work with them (moving them around, editing details, etc.) except through programs running with that other user's access. When I accepted that and tried to proceed anyway, for the sake of experimentation, IIRC, I ran into obstacles trying to set up the necessary virtual hardware for the VM - in particular, IIRC, a virtual CD drive pointed at the ISO that would be used to install the OS. (This part I am less certain about than even the above; it's been rather a while, and I was stressed enough by the time I hit this point that I may have blanked out more of the details in self-defense.) At that point, I gave up, at least in part for the sake of not piling more and more stress on myself trying to get the ability to do things that would hopefully enable me to reduce stress in other areas. (Writing this mail is already bringing back up all that stress, and I hope it will not just wind up making things worse.) So... either I somehow have managed to do things *100% completely wrong*, or the workflow with virt-manager is not even remotely as straightforward(ly usable) as the one I see with VMWare Workstation and think I remember seeing with VirtualBox. I would *love* to be wrong about that, because there is a *lot* of stuff that I'd like to do that would be *far* easier if I had discardable VM snapshots to do it in. However, I also do not have the personal stress to spare for experimenting with this blindly and bashing my head against walls getting nowhere in those experiments. If there *is* a way to get virt-manager to support a VMWare( and, I think, VirtualBox)-like workflow - with support for hierarchical nested snapshots, and graphical management thereof, among other things - and have things more-or-less Just Work, I would *love* to learn about it. -- The Wanderer The reasonable man adapts himself to the world; the unreaso
Re: Date time problem bookworm, fvwm....
On 2023-10-22 at 07:24, to...@tuxteam.de wrote: > I better not tell. My clock is a... shell script in a tiny Xterm > which also shows my battery status. Ooo, that sounds interesting. I don't currently have a laptop, so the battery-status part wouldn't currently apply, but this sounds like something I might like to try when that changes; any chance of sharing the specific details? > But I'm weird. I literally used to go by "Weird" as a nickname, though (sadly?) it never became as commonly used as with Al. Weird doesn't bother me at all. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Strange Monitor Behavior
On 2023-10-16 at 10:17, Thomas Schmitt wrote: > Hi, > > my ~ 10 year old Iiyama ProLite X2775HDS sometimes does strange > things when i wake it by keyboard or mouse movement after X had cut > off itsi signal because i was inactive for a few minutes. > > Either it stays black although it reported to have in nput signal > again, or it shows an interlaced and displaced image of what fvwm is > supposed to display. A power cycle of screen reliably brings the > correct display. FWIW, that "interlaced and displaced image" sounds like it could be describing the same "fuzzy"/"blurry" thing I was trying to describe. > In more than 99 of 100 tries it just wakes up ok, though. Same. > It seems not to be related to the computers to which it has been > attached since i got it. I only use the monitor with one single computer, thus far, so I can't testify on that front. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Strange Monitor Behavior
On 2023-10-16 at 09:22, Stephen P. Molnar wrote: > I am running up top date Bookworm on my AMD Linux platform with a LG > Monitor and have developed a rather strange problem. > > When the system wakes up from sleep mode it has a bright pink screen. > This seems to be a random occurrence. Turning the Monitor off and > then back on returns the normal screen. > > The monitor card is a Visiontek Radeon HD 5450. That sounds peripherally similar to a behavior I've occasionally seen; I haven't seen the pink screen, but I *have* seen the monitor wake up to a state of producing a "fuzzy" or "blurry" display. As with what you describe, the behavior persists until the monitor is power-cycled, and clears after that (until the next time). I've always interpreted that as being an issue with the monitor, not with the GPU or with the controlling software. If that's correct, and the issue you're seeing is of the same type, then the exact model of the monitor you're seeing the pink screen with would probably be relevant. (I don't remember offhand whether the behavior I'm describing was seen with my current monitor or with a previous one, so I can't provide the exact model for my own case either, although I can state that both candidates are Dell units.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: How can I find packages manually installed using "dpkg -i"?
On 2023-10-02 at 09:52, Greg Wooledge wrote: > On Mon, Oct 02, 2023 at 09:43:39AM -0400, The Wanderer wrote: > >> On 2023-10-02 at 09:28, Ottavio Caruso wrote: >> >>> Yeah, the one for which I had to manually use "dpkg -i". >> >> That information is not tracked. >> >> What is tracked is "the package versions known to be available from >> each registered repository" and "the package versions which are >> installed". > > There *is* tracking. Packages can be marked as "automatically > installed" or not. The problem is, the marking is not consistent > with user expectations. That does exist, yes, but it tracks "explicitly selected for installation" vs. "installed as a dependency" - and even beyond the problems which you note, that isn't the distinction which Ottavio appears to be interested in. The distinction Ottavio is interested in appears to be "installed by 'dpkg -i' from a .deb file on the command line" vs. "installed via 'apt' or 'apt-get' from a repository". (It's not clear how "installed via 'apt' from a .deb file on the command line" would be counted for this purpose.) As far as I'm aware, there is no tracking of where the package entered the local system from, which is what would be necessary in order for something to report the information Ottavio appears to be seeking. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: How can I find packages manually installed using "dpkg -i"?
On 2023-10-02 at 09:28, Ottavio Caruso wrote: > Am 02/10/2023 um 10:12 schrieb Marco M.: > >> That means it cannot be found in the currently enables repos. >> >> Do you want to list such packages > > Yeah, the one for which I had to manually use "dpkg -i". That information is not tracked. What is tracked is "the package versions known to be available from each registered repository" and "the package versions which are installed". Whether the package version that is installed came from one of the registered repositories, much less whether it was installed from that repository, is not tracked. Unless I'm much mistaken, if you installed one package manually (i.e., not as a dependency) from a repository and another package locally via 'dpkg -i', the installation state of those two packages will look the same. The system does not track anything which would let it tell you where the package came from; at most, if the installed version of a package is available from a currently-registered repository, it may be able to tell you where you could get that package from again. It's entirely probable that there is no way to identify the set of packages you're interested in, short of a combination of manual archaeology in local log files (and the local apt package cache) and relying on your own memory. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian will not boot any more, wrong UUID
On 2023-10-01 at 17:39, The Wanderer wrote: > On 2023-10-01 at 15:36, Hans wrote: > >> Hi the Wanderer, >>> (If you're unlucky, there may not *be* any such driver for that >>> model, or at least not one you can get your hands on. In which >>> case, barring the downgrade-the-firmware angle, you'd probably >>> be out of luck.) >> >> I guess I am unlucky. :) > > I don't think we've reached the stage of concluding that there is no > such Linux driver, at least not yet. > > What steps have you taken to try to identify the device for which a > driver is needed? > > A 'lspci' verbose report, from one of the live environments where > the NVMe device does not appear, might be helpful as a starting point > in doing that. I'd probably start with 'lspcn -nnn', and look in the > output for either anything which mentions "NVM" or "nvm", or any > unidentified devices. Mrph. I of course meant 'lspci -nnn'. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian will not boot any more, wrong UUID
On 2023-10-01 at 15:36, Hans wrote: > Hi the Wanderer, >>> Second: The setting of AHCI has disappeared, so I can not change >>> the settings in BIOS. And: the BIOS can not be reflashed! >> >> Please describe exactly what you have done to try to downgrade the >> UEFI (which isn't a BIOS, as I understand the definitions of those >> terms, but may sometimes be called one). > > In short; I tried (as most people tell): Starting windows in secure > mode, then boot into the BIOS and there set from RAID to AHCI, > afterwards start windows as normal. > > This setting in BIOS was existent some time ago, but now it is > complete gone (this point is completele disappeared!)!! I know that > it is in RAID, because Windows told so: BUS form = RAID. I apologize; it seems I was not sufficiently clear. By "downgrade the UEFI" I meant "revert the installed UEFI to an older version" - what you were attempting to do by "reflash"ing the "BIOS". I was looking for a response like "double-clicked the EXE which I got from [place] and followed the prompts, selecting [option] when given a choice" or "ran the EXE which I got from [place] from the command line, using [list of command-line parameters]". If you did it via a graphical interface, and ran into a no-downgrade wall, it may well be worth looking at the documentation which is probably available along with the download; it may provide a command-line version of the process, which might support parameters to tell the tool to allow the downgrade to occur. (Downgrading is suboptimal, but would be one way to address the proximate issue.) >> If you can get the "AHCI" option back, then that is almost >> certainly going to be the simplest way to fix the problem (or at >> least to move on to the next stage of the problem, which would >> probably be more tractable). >> >> If you can't, then the solution is likely to require getting a >> compatible driver in the Linux environment (whether live or >> otherwise) that you're using to try to access the system. The >> details of *that* are not something that I have sufficient >> experience with to want to try to advise someone on at a distance. > > Yes. I am wondering, why the debian installer DVD does not see the > nvme- device. When I installed Debian_11 a year ago, it did see the > drive. Of course I tried with this DVD again to reinstall, but today > it does not see the drive any more (I suppose because of RAID). My first suspicion would be that the installer environment does not include - or, at least, is not loading - the necessary drivers for some portion of the stack which is in use when the "RAID" option is enabled. >> (If you're unlucky, there may not *be* any such driver for that >> model, or at least not one you can get your hands on. In which >> case, barring the downgrade-the-firmware angle, you'd probably be >> out of luck.) > > I guess I am unlucky. :) I don't think we've reached the stage of concluding that there is no such Linux driver, at least not yet. What steps have you taken to try to identify the device for which a driver is needed? A 'lspci' verbose report, from one of the live environments where the NVMe device does not appear, might be helpful as a starting point in doing that. I'd probably start with 'lspcn -nnn', and look in the output for either anything which mentions "NVM" or "nvm", or any unidentified devices. > Thanks for the help. You're quite welcome. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian will not boot any more, wrong UUID
On 2023-09-30 at 11:34, Hans wrote: > Dear folks, > > since days I am now fighting with a big and special problem I fell > into. > > On my notebook I have 2 drives, one is a NVME drive, the other a > normal harddrive. > > The NVME has got Widows_11 and Debian_12 on it. > > But here is the problem: > > As I resized the Windows and Linux partitions, the UUIDs have > changed. Thus, now the root partition can not be found any more, as > the UUID has changed. Having read over the rest of this thread, so far I do not see anything to indicate that the UUID has changed. > This is not the only problem! Windows has changed the BIOS settings > during an update. Now it has set from AHCI to RAID. This is the first > problem. Rather, I think that this is likely to be the entire problem. At least on some (many?) systems, when this is set to RAID rather than AHCI, a different driver is required. When that driver is not present or is not compatible with the hardware, Linux will not see the storage device. That is the symptom which you are seeing, and because of that, I think that this is the cause you need to deal with. It is possible that the UUID of the storage device and/or the partitions on it may have also changed, but until the storage device is accessible from Linux again, the question of whether it has or not is irrelevant. > Second: The setting of AHCI has disappeared, so I can not change the > settings in BIOS. And: the BIOS can not be reflashed! Please describe exactly what you have done to try to downgrade the UEFI (which isn't a BIOS, as I understand the definitions of those terms, but may sometimes be called one). It's possible that there may be parameters which you could pass to the tool you're using to try to do this, which would override the refusal to downgrade. If you can get the "AHCI" option back, then that is almost certainly going to be the simplest way to fix the problem (or at least to move on to the next stage of the problem, which would probably be more tractable). If you can't, then the solution is likely to require getting a compatible driver in the Linux environment (whether live or otherwise) that you're using to try to access the system. The details of *that* are not something that I have sufficient experience with to want to try to advise someone on at a distance. (If you're unlucky, there may not *be* any such driver for that model, or at least not one you can get your hands on. In which case, barring the downgrade-the-firmware angle, you'd probably be out of luck.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: CVE-2023-5217 unimportant for firefox?
On 2023-09-30 at 07:20, hede wrote: > Hi, > > does anyone know why CVE-2023-5217 (critical vp8 encoder bug) is rated as an > "open unimportant issue" for firefox-esr? Currently it is not fixed in > bookworm and newer [1]. Mozilla itself rates it as "critical" [2]. > > [1] https://security-tracker.debian.org/tracker/source-package/firefox-esr When I follow the link to [3], and look at the bottom of the page, I see what looks to me like an explanation: >> src:firefox, src:firefox-esr and src:thunderbird use the system >> libvpx starting in bookworm and above. For older releases still >> needs the fixes in src:firefox-esr and src:thunderbird. [3] https://security-tracker.debian.org/tracker/CVE-2023-5217 -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian live boot corrupting secure boot
On 2023-09-28 at 05:16, Valerio Vanni wrote: > On Wed, 27 Sep 2023 22:14:57 -0400 The Wanderer > wrote: >>> But this way I would have to disable secure boot to load old Clonezilla. >>> Disable secure boot, launch clonezilla, restore image, reenable secure >>> boot, start OS. >> >> Well, why do you need to load old Clonezilla? Surely the new version of >> the Clonezilla live boot environment should work just as well as the old >> one? > > I never found backward compatibility in Clonezilla versions, I remember > only a forward one a couple of years ago. > > The reason is that the new version doesn't work as well as the old one. > It works, but performance has dropped to the floor. Disk image creation > is ok, image restore is too slow if destination is an NVME drive. > > It's a serious difference, I'm not a maniac that crave for milliseconds. > In numbers: 2.8.1-12 restores a Windows main partition in 6-7 minutes, > next version 3.0.x takes 1 hour and 50 minutes. Notice: same image, from > same source to same destination. Yow. That's a pretty serious regression. > Latest one 3.1.x are better, but they still take 70-72 minutes. That's better, as you say, but still a pretty serious regression. I see that you've filed a bug report [1] about this, which appears to be getting active(-ish) attention, so that's good; this thread is then just about something problematic-seeming that you've encountered when trying to work around the problem. [1] https://sourceforge.net/p/clonezilla/bugs/395/ -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian live boot corrupting secure boot
On 2023-09-27 at 18:04, Valerio Vanni wrote: > Il 27/09/2023 05:22, Jeffrey Walton ha scritto: > >> On Tue, Sep 26, 2023 at 10:20 PM Valerio Vanni >> wrote: >>> 3) At next boots, secure boot refuses to boot from Clonezilla >>> live 2.8.1-12. The error is >>> "verification failed 0x1A security violation" >>> Windows 10 can still start, and shows secure boot active. Only if >>> I disable secure boot from BIOS, I can start clonezilla. >>> >>> 4) I reflash BIOS, same version, and go to point 1. >>> >>> Tested many times. >> >> The failure at (3) sounds like what happened when old grub images >> were blacklisted in the UEFI Revocation List dbx. Also see >> <https://lwn.net/Articles/827403/>. >> >> You should probably stop doing (4). > > But this way I would have to disable secure boot to load old Clonezilla. > Disable secure boot, launch clonezilla, restore image, reenable secure > boot, start OS. Well, why do you need to load old Clonezilla? Surely the new version of the Clonezilla live boot environment should work just as well as the old one? The only candidate reasons I can think of are "I have data files which I still need to use with the Clonezilla live boot environment, and the old version includes tools which are compatible with those files, but the new one does not", and "I have a lot of already-created boot media with the old version of the Clonezilla live boot environment, and I don't want to discard or re-create all of that boot media". The former would be a valid reason, but would also seem a bit odd; backwards-incompatible breaks like that do not AFAIK tend to come along very often, especially not in system-imaging solutions. The latter would be understandable, but you'd have the choice between doing that discard-all-the-old thing, or living with the downsides of disabling Secure Boot. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: [a bit OT] Automate a (G o o g l e) search from a list of strings
On 2023-09-20 at 16:50, Tom Browder wrote: > On Wed, Sep 20, 2023 at 13:36 Nicolas George > wrote: > >> Tom Browder (12023-09-20): >> >>> What if you used an equilavent script but increased and >>> randomized time > > ... > >> We can try to exercise some common sense, in particular by >> comparing to similar situations. For example, if you take something >> that does not belong to you, but do it at night, when everybody is >> sleeping and being very careful you do not make a step squeak or >> break the laser beams, is it still stealing? > > I apologize. I was not referring to stealing, and I haven't read the > details in the terms of use. What I should have asked was: "is a > single query in the script okay?" If so, how much time would have to > pass before the next query in order to adhere to the terms of > service? You'd have to refer to the TOS to be certain, but based on the way they've been described here, it isn't a question of amount of time. It's the fact that you're applying scripts and automation at all, vs. having each search be individually triggered by (and, I suspect, the results sent/shown to) a real-person user. Yes, this is horrific in light of the fact that automation is what computers are *for* - but it also makes sense from Google's likely perspective, and it's entirely plausible that they might care enough to try to detect even minimal amounts of automation. In principle, it probably *would* be possible to script doing such a thing in such a way that it would not be sufficiently distinguishable from human access patterns for them to be able to tell. (Varying time between accesses almost certainly would not do it; among possibly other things, you'd need to specify the accessing program, etc., in a way that is doable but not necessarily obvious.) That said, you'd be taking a gamble that your ability to obfuscate such things is better than Google's ability to detect it. Who would you prefer to bet on in a competition like that? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: bookworm and network connections
On 2023-09-01 at 16:50, Greg Wooledge wrote: > On Fri, Sep 01, 2023 at 08:32:40PM +, Michael Kjörling wrote: > >> I don't think /etc/rc.local is executed by default on modern Debian >> systems. Have you checked to make sure that rc-local.service is >> enabled and actually gets started during boot? Is there anything >> relevant in the logs for that? Is /etc/rc.local set as executable? > > The rc-local.service is enabled by default. It will execute /etc/rc.local > if it exists and is executable. > > The Debian installer used to create a stub /etc/rc.local file which had > a correct shell script shebang, and the necessary permissions. This is > longer created during installation, so the user would need to create > it themselves, if they want to have it. They'd also have to know enough > to put a correct shebang on it, and to do chmod +x. That's not a huge > barrier to entry, but it's just enough to confuse some people. It's actually still available, although I expect you're right that in a default configuration it won't be installed during Debian installation: $ dlocate /etc/rc.local initscripts: /etc/rc.local $ apt-cache policy initscripts initscripts: Installed: 3.07-1 Candidate: 3.07-1 Version table: *** 3.07-1 900 900 http://ftp.us.debian.org/debian testing/main amd64 Packages 900 http://ftp.us.debian.org/debian testing/main i386 Packages 100 /var/lib/dpkg/status $ cat /etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. if test -d /etc/boot.d ; then run-parts /etc/boot.d fi This is in an environment that's running sysvinit, not systemd; 'sysvinit-core' currently depends on the 'initscripts' package. I'm not in a position to tell whether there would be issues trying to install 'initscripts' in a systemd environment, but I just offhand wouldn't particularly expect there to be. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Sleep: out of control
On 2023-08-31 at 13:03, zithro wrote: > On 31 Aug 2023 14:17, Tom Browder wrote: > >> Note: The systemd "/etc/systemd/sleep.conf" file has all entries commented >> out. > > Take care, commenting may NOT be the same as disabling/setting to NO ! > > Each software has its own rules, but _usually_ when you comment out the > lines, the app built-in defaults will be used (like openssh). > Systemd behaves like that, at least that's what I observed after > commenting out the NTP server lines of systemd-timesync. In this case, on my system, the file in question begins with a comment that includes the following lines: # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. In other words: the commented-out entries are present to document both what the available configuration settings are, and what values will be used for those settings if you do not set them to something else. Leaving them commented does not set them, so unless they are somehow set elsewhere, that means that the value shown in the comment will be used. (Assuming that the component which handles those settings is going to run at all, that is. As has been suggested, masking / etc. the appropriate service would probably prevent that.) Tom, does your version of that file not include a comment with that same information? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: debian image questions
On 2023-08-03 at 15:59, debian-u...@howorth.org.uk wrote: > Andy Smith wrote: >> Hi Bill, >> >> Your question is more suited to debian-user so I've redirected >> there. Please send replies there (I've set reply-to for that >> purpose also). >> >> On Wed, Aug 02, 2023 at 08:40:51PM -0400, Bill Miller wrote: >>> why cant i just install Debian from a digital cloud? i dont >>> understand why i need physical hardware to run digital software? >>> >> >> You don't. Roughly 60% of our customers choose Debian¹ (another >> ~30% Ubuntu) to run on their virtual machines and Debian is >> available on all major clouds. Also if you prefer container >> technology like Podman or Docker, Debian is represented on those >> registries also. >> >> What are you actually trying to do? > > I suspect you both may be misinterpreting the OP's question. I think > he is asking about doing a net install without needing to start with > a USB stick or similar. I agree, that's the direction of the original question: "why do I have to create physical (boot) media in order to install Debian, instead of being able to just initiate the install by clicking a button on a Website, as I can do with so many other things?". (Where "clicking a button on a Website" can include initiating a download that then gets automatically run, or that the browser then prompts you to run.) > AIUI the issue is that the installer is started by booting the > system into it, so some bootable device is needed to boot from. > Whether it would be possible for some application to be written for > linux and/or Windows and/or MacOS etc that downloaded the installer > and booted into it I don't know, but I see some obvious > difficulties. Based on shenanigans I've seen people get up to in classes at the college where I work, I'm nearly certain that it would be possible to create a Windows executable which would dump specified data into a disk-image file on the hard drive, and modify the Windows boot configuration to include a boot entry which points to that disk image, and possibly also even modifies the boot setup so that the next boot will automatically use that new boot entry (or at least prompt you to select which boot entry to use). If you then make that disk-image file pivot into the equivalent of an initrd, so that it's free to repartition the hard drive even if that means wiping it, then it should be entirely possible to get into the same installer environment as you could get to with bootable install media. Whether doing that would be either advisable or practical, however, is much a different question. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Why does Debian have code names for releases?
On 2023-06-26 at 11:40, Kent West wrote: > On Mon, Jun 26, 2023 at 10:29 AM Arno Lehmann wrote: > >> >> Also, I struggle with the names, always need to go to the project web >> page or wikipedia if I need to look up which version has which name, and >> it's always a nuisance. >> > > Code-names are awesome. I prefer them to be something like "First" or > "Secundo" or "Twelve" If you think the Debian release codenames are bad, take a look at the release labels mentioned in /usr/share/doc/nano/changelog.Debian.gz. The last several releases listed have the following changelog entries: * The "Duque de Feria" release. * The "Explicaciones, ¿de qué? Jajaja" release. * The "Cent anys de Joan Fuster" release. * The "Home Petrov, si soc jo!" release. * The "Blue checkmark" release. And this is fairly typical; the least typical of those is the last, which is actually in recognizable English, and references something that I actually recognize. I have no information about the background to this, at all. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bluetooth driver error on boot after upgrade to bookworm
On 2023-06-16 at 11:00, Unni wrote: > Hello, > > I am getting Bluetooth firmware error after upgrade. I've tried > reinstalling firmware-iwlwifi. But no luck. I've added non-free-firmware > in apt source, so thats not the issue. Help me to fix the error on booth. From that last, I'm presuming that you've rebooted since the upgrade, and that it's at boot time that the error appears. > ~# dmesg | egrep -i 'bluetooth' > [6.051557] Bluetooth: Core ver 2.22 > [6.051579] NET: Registered PF_BLUETOOTH protocol family > [6.051580] Bluetooth: HCI device and connection manager initialized > [6.051587] Bluetooth: HCI socket layer initialized > [6.051589] Bluetooth: L2CAP socket layer initialized > [6.051593] Bluetooth: SCO socket layer initialized > [6.093212] bluetooth hci0: firmware: failed to load > intel/ibt-20-0-0.sfi (-2) > [6.093358] bluetooth hci0: firmware: failed to load > intel/ibt-20-0-0.sfi (-2) I see some things online that seem to suggest that this may be a misleading message, and that the stack may already be using the available firmware, but is also attempting to load this lower version and is reporting that that attempt failed. However, those mentions are somewhat older (2021-ish?), and the messages aren't quite the same, and it looks like they should have been fixed by now, so I'm not assuming that they're talking about this same thing. Can you confirm whether you're seeing any actual functionality issues along with this change, or whether it's just the fact that the message is appearing that has you concerned? FWIW, I get all of the above messages except the two about firmware (I get two about a command timeout and a "Reading Intel version command failed" instead)... > [7.622442] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 > [7.622446] Bluetooth: BNEP filters: protocol multicast > [7.622450] Bluetooth: BNEP socket layer initialized ...and also get these three... > [7.623488] Bluetooth: MGMT ver 1.22 > [9.011767] Bluetooth: RFCOMM TTY layer initialized > [9.011779] Bluetooth: RFCOMM socket layer initialized > [9.011784] Bluetooth: RFCOMM ver 1.11 > [ 32.748460] Bluetooth: hci0: Opcode 0x 401 failed: -16 ...but not these. I don't actually know whether Bluetooth functionality is available on my system, because I don't think I have any hardware suitable to pair to it. Presumably, however, the lines we have in common should not be relevant to what you're seeing. $ apt-file search ibt-20-0- firmware-iwlwifi: /lib/firmware/intel/ibt-20-0-3.ddc firmware-iwlwifi: /lib/firmware/intel/ibt-20-0-3.sfi (This is with the same package version you referenced; it's in both stable and testing, at the moment.) So ibt-20-0-3.sfi exists, but not the 20-0-0 version. The question would then seem to be why the Bluetooth stack is attempting to load that lower-numbered version. Given that we're talking about firmware, it may be necessary to reinitialize the relevant modules (et possibly cetera) after the upgrade; that can almost certainly be done by rebooting, but should also be possible to do manually in many cases by removing and reinserting modules. If (as suggested above) you've rebooted, then presumably this approach has already been tried. (In my case, I'm fairly sure I haven't rebooted since the release, but I was also tracking testing right up to the release so I'm already running the same kernel etc. that you mentioned.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Strange message
On 2023-06-15 at 08:38, Cindy Sue Causey wrote: > No answer, only adding in hopes that it helps trigger an ah-ha moment > for someone. I've been seeing a FAILED alert on every reboot. > Ultimately, it points at multiple lines such as: > > /var/log/user.log:2023-06-13T21:43:42.789226-04:00 northpole > lightdm[1881]: Error getting user list from org.freedesktop.Accounts: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.freedesktop.Accounts was not provided by any .service files I'm very far from being a D-Bus expert, but I suspect that this is almost certainly completely unrelated to the message reported by the OP. On current testing, 'apt-file search org.freedesktop.Accounts' finds a few items (including one 'org.freedesktop.Accounts.xml') in the package 'accountsservice'. The description of that package states that >> The AccountService project provides a set of D-Bus >> interfaces for querying and manipulating user account >> information and an implementation of these interfaces, >> based on the useradd, usermod and userdel commands. and on the basis of that, my guess would be that you don't have this package installed, and something in your reboot process is attempting to query those D-Bus interfaces just in case they're present, but since they aren't, you see these error messages. (It may or may not be possible for another package to provide the same interfaces without providing those filenames; my guess would be that it is, but I don't know how to go about identifying any such package that may be available.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian home page -> Download link broken:
On 2023-06-12 at 18:55, David Wright wrote: > On Sun 11 Jun 2023 at 19:18:15 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 17:36, David Wright wrote: >>> There are several sources: > > [ snipped the back and forth ] > > I'm sorry, but I just can't take seriously your not being acquainted > with the term "release". Please don't put words in my mouth. Of course I'm familiar with that term. I just don't think of it when updating, perhaps in part because I update routinely when a release has not happened. Regardless of what you can or cannot take seriously, the fact is that in *none* of the cases thus far when I have encountered this message did the term "release" occur to me as something that I might search for, except in hindsight after having already encountered the '--allow-releaseinfo-change" argument name. >>> AIUI, it contains the string InRelease, according to >>> https://lists.debian.org/debian-user/2023/06/msg00392.html in >>> this thread. >> >> I consider that to be part not of the error message, but of the >> repository identifier being referenced *by* the error message. (The >> same would be true for the labels 'bookworm' and 'trixie'.) It did >> not occur to me to use that as an indicator of what to search for, >> and if it had, it would have led me to search not for 'release' but >> for 'InRelease' - since I consider that latter to be a discrete >> term of its own. >> >>> Debian's use of camelCase makes it easy to decompose the word. >>> As pointed out above, the man page that the Note directs you >>> (apt-secure) to uses Release rather than InRelease in all but >>> two places. >> >> I don't think of "InRelease" as being a word, but as being a >> filename that's presumably used on the repository servers and >> checked for by the update tooling - i.e., as an implementation >> detail, which is irrelevant to anyone not attempting to investigate >> the innards of that tooling or those servers. > > AFAICT the file InRelease is always accompanied by Release and > Release.gpg files. That seems plausible, though again it's an implementation detail which the end user doesn't need to know about, and was not referenced in the presented messages. In case it helps make my perspective more comprehensible: I've been seeing the term "InRelease" for all these years, in the output of 'apt-get update' as an apparent file file which is being downloaded and presumably parsed. There's never been any information provided as to what it is, and there's been no apparent benefit to trying to find out. (There are other terms used in that output, such as 'rred', which it seems entirely fruitless to even attempt to find any documentation for; I've actually found an explanation for that such-as example once, but don't remember the explanation, and have never been able to find it again.) Based on that experience, I no longer think of 'InRelease' as being anything but an unexplained internal detail of the 'apt-get update' process - one which it shows during its progress messages because that makes a helpful landmark for keeping track of where in the update process you are, in case there's a need to troubleshoot an issue. It has connotations in my mind of an opaque, discrete object, which there is no point in investigating or thinking about except in terms of that "here's where the failure occurred" type of troubleshooting. I certainly don't think of it as being a reference to a codenamed "release", except perhaps by some historical origin of the filename; I don't particularly think of it as *not* being that either, however, because I simply *do not think about it at all*. I'd have been as likely to think that its name referred to the releases of individual packages which are indexed within the file (i.e., "packages which are in a released state"), or something like that, as to think that it referred to a codenamed Debian release - if, again, I bothered to think about it at all. ...I've forgotten why I was writing the above paragraphs, or if there was a concluding point I was trying to reach, although if there was I think I'd have covered all the necessary ground before the point itself. >>> I don't know whether or which of your extra repositories use >>> stable/ testing as suites/codenames, so I can't opine on that. >> >> I wasn't thinking of it as applying only in cases where the >> symbolic names 'stable' and 'testing' are used; I'm pretty sure it >> would apply to any repository that uses a symbolic name rather than >> a release-specific codename, and there's nothing restricting >> symbolic names to those two. >> >> That said, as far as I recall I don't
Re: RAM
On 2023-06-12 at 17:47, Bret Busby wrote: > On 13/6/23 04:52, The Wanderer wrote: >> I have to apologize; I completely misremembered the name of the program >> that I was referencing, probably because of the filenames I store its >> output under. hwinfo is absolutely not it. I would not consider output >> such as you presented to be appropriately readable for human >> consumption. >> >> Rather, I got the records I'm looking at from the program 'lshw'. >> > Okay - so the equivalent output that describes the memory, from lshw, is > > " > *-memory >description: System Memory >physical id: 2f >slot: System board or motherboard >size: 128GiB >capabilities: ecc >configuration: errordetection=multi-bit-ecc > *-bank:0 > description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns) > product: M393A2G40DB0-CPB > vendor: Samsung > physical id: 0 > serial: 400F4723 > slot: DIMM1 > size: 16GiB > width: 64 bits > clock: 2133MHz (0.5ns) > which may appear to be more "human" understandable, for expressing > the capacity of each DIMM card in GiB, rather than in bytes, Actually, that isn't what I found more readable about this. It's more the separate indented blocks for each distinct item being described, and the use of lowercase rather than ALL_CAPS field labels, that makes the difference. > but, I had no problem in finding and understanding the applicable > output for describing the RAM component of the hardware. > > If being able to adequately interpret the output from hwinfo, makes > me other than human, well, such is life. Oh, certainly not. I can read the other myself, it's just that I understand myself as doing so through the lens of "thinking like a computer", similarly to the mindset I find myself in when reading source code. > Both utilities work, and, work sufficiently. > > hwinfo is simply less pretty than lshw. > > But, it nevertheless, works. It certainly does. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: RAM
On 2023-06-12 at 16:45, Bret Busby wrote:
> On 13/6/23 04:30, The Wanderer wrote:
>
>> On 2023-06-12 at 16:06, Mick Ab wrote:
>>
>>> I wish to obtain information about the RAM installed on my PC using the
>>> command line. The information needed is :-
>>>
>>> Total RAM stored
>>> Number of sticks used and amount of RAM on each stick
>>> Type of RAM e.g. DDR4
>>> Speed of RAM e.g. 3200 MHz
>>> Manufacturer and model number of RAM
>>>
>>> I have seen the dmidecode command being used, but the reliability of the
>>> information returned is not reliable.
>>>
>>> Is there any command that will reliably give the required RAM information ?
>>
>> There are probably multiple ways to get it, but the first one that comes
>> to my mind involves the 'hwinfo' command, from the package of the same
>> name.
>>
>> I don't remember exactly how I invoked it, but I have a historical trail
>> of files listing the hardware specifications of my last few machines as
>> they've changed over time, each generated from the output of that
>> command.
>>
>>
>> If I search the latest such file for "DIMM", I see two entries, each for
>> a different DIMM (i.e., "RAM stick"), each with multiple data items. The
>> fact that there are two of them gives you the "number of sticks used"
>> you asked for.
>>
>> Those entries are sub-entries of a larger entry called "memory", which
>> has a data item called "size", which is the "total RAM" you asked for.
>>
>> One of the data items in each sub-entry is "product", which appears as
>> if it might be the "model number" you asked for. (It certainly looks
>> like a model number, anyway.)
>>
>> Another is "vendor", which appears to be the "manufacturer" you asked
>> for.
>>
>> Another is "size", which gives you the "amount of RAM on each stick" you
>> asked for.
>>
>> Another is "clock", which is the "speed of RAM" you asked for.
>>
>> Another is "description", which at least in my case specifies (as part
>> of what appears to be a freeform string) that the DIMMs I'm looking at
>> are DDR4. I don't see that information specified anywhere else in the
>> listing.
>
> From the above, whilst this computer is running Linux Mint Mate 21.1,
> which is based (?) on Ubuntu 22.04 ("jammy"), rather than Debian, I
> expect that the same will apply for Debian;
> Tue Jun 13 04:33:23 bret@bret-Precision-Tower-5810:~$hwinfo
> and, in the output (lots of it - it outputs alot of details), is
>
> "
> P: /devices/virtual/dmi/id
>L: 0
>E: DEVPATH=/devices/virtual/dmi/id
>E: SUBSYSTEM=dmi
>E:
> MODALIAS=dmi:bvnDellInc.:bvrA34:bd10/19/2020:br65.34:svnDellInc.:pnPrecisionTower5810:pvr:rvnDellInc.:rn0K240Y:rvrA02:cvnDellInc.:ct7:cvr:sku0617:
>E: USEC_INITIALIZED=2533353
>E: ID_VENDOR=Dell Inc.
> E: ID_MODEL=Precision Tower 5810
>E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
>E: MEMORY_ARRAY_EC_TYPE=Multi-bit ECC
>E: MEMORY_ARRAY_MAX_CAPACITY=137438953472
I have to apologize; I completely misremembered the name of the program
that I was referencing, probably because of the filenames I store its
output under. hwinfo is absolutely not it. I would not consider output
such as you presented to be appropriately readable for human
consumption.
Rather, I got the records I'm looking at from the program 'lshw'.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Re: RAM
On 2023-06-12 at 16:06, Mick Ab wrote: > I wish to obtain information about the RAM installed on my PC using the > command line. The information needed is :- > > Total RAM stored > Number of sticks used and amount of RAM on each stick > Type of RAM e.g. DDR4 > Speed of RAM e.g. 3200 MHz > Manufacturer and model number of RAM > > I have seen the dmidecode command being used, but the reliability of the > information returned is not reliable. > > Is there any command that will reliably give the required RAM information ? There are probably multiple ways to get it, but the first one that comes to my mind involves the 'hwinfo' command, from the package of the same name. I don't remember exactly how I invoked it, but I have a historical trail of files listing the hardware specifications of my last few machines as they've changed over time, each generated from the output of that command. If I search the latest such file for "DIMM", I see two entries, each for a different DIMM (i.e., "RAM stick"), each with multiple data items. The fact that there are two of them gives you the "number of sticks used" you asked for. Those entries are sub-entries of a larger entry called "memory", which has a data item called "size", which is the "total RAM" you asked for. One of the data items in each sub-entry is "product", which appears as if it might be the "model number" you asked for. (It certainly looks like a model number, anyway.) Another is "vendor", which appears to be the "manufacturer" you asked for. Another is "size", which gives you the "amount of RAM on each stick" you asked for. Another is "clock", which is the "speed of RAM" you asked for. Another is "description", which at least in my case specifies (as part of what appears to be a freeform string) that the DIMMs I'm looking at are DDR4. I don't see that information specified anywhere else in the listing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian home page -> Download link broken:
On 2023-06-11 at 17:36, David Wright wrote: > On Sun 11 Jun 2023 at 09:32:04 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 09:05, David Wright wrote: >>> It would seem very simple, the first time this happens, to >>> configure this in APT. I typed man apt-get (my preferred >>> method), /release >> >> Where did you come up with the 'release' search term? > > There are several sources: > > Project News News and Announcements about Debian 10June2023 Debian 12 > "bookworm" released; > > (remove the inflection from "released".) That assumes you've seen an announcement; this cycle, I don't think I had, and certainly not everyone will have been in a place to do so. > apt/apt-get man pages use release in their SYNOPSIS sections; As part of the "replace this with a real example of the class" keyword 'target_release', and not anywhere else. I certainly would not have thought of this as suggesting something to search for in the man page, or as being related to this error message. > From the term "Release Notes"; Release notes are not in my mind when I'm updating. That they are in yours indicates, as was probably already clear, that we think about these things differently. > From conversations on debian-user; > > (search for "release", and the most recent 100 matching posts in > 80,000 have a date range of just two months.) I've been reading debian-user for years on end, and it did not lead me to think of this as a search term to try. > From the error message printed when the release change fails, or the > confirmation when it succeeds (IIRC); > > (Since the time when signatures were included in Release files, > "Release" has been heavily camouflaged with the prefix "In".) See below. > From the apt-secure man page, which is mostly about Release files. This could be interpreted as a hint, I'll admit, but it did not occur to me as one when I was looking at that page. >> I don't remember what I searched for in the apt-get man page when >> I first encountered this message, but whatever it was, I didn't >> find anything relevant. >> >> Regardless, the apt-get man page isn't the one to start with, >> because it's not the one the error message directs you to. The >> error message directs you to the apt-secure man page, which does >> not provide any useful information about how to resolve the error >> message. > > Granted, that note might be improved, but as it was apt-get that > provoked the Error message, it would be natural to check out its man > page too. Indeed so, but I didn't find anything useful from searching for "update', which was the action I'd attempted to take. It did not occur to me to search for "release"; nothing I could see in the context brought that string into relevance. >> The error message also does not include the string 'release', in >> any capitalization variant, so that doesn't provide a hint for what >> to search for either. > > AIUI, it contains the string InRelease, according to > https://lists.debian.org/debian-user/2023/06/msg00392.html in this > thread. I consider that to be part not of the error message, but of the repository identifier being referenced *by* the error message. (The same would be true for the labels 'bookworm' and 'trixie'.) It did not occur to me to use that as an indicator of what to search for, and if it had, it would have led me to search not for 'release' but for 'InRelease' - since I consider that latter to be a discrete term of its own. > Debian's use of camelCase makes it easy to decompose the word. As > pointed out above, the man page that the Note directs you > (apt-secure) to uses Release rather than InRelease in all but two > places. I don't think of "InRelease" as being a word, but as being a filename that's presumably used on the repository servers and checked for by the update tooling - i.e., as an implementation detail, which is irrelevant to anyone not attempting to investigate the innards of that tooling or those servers. >>> and Space N three times, which showed: >>> >>> --allow-releaseinfo-change >>> Allow the update command to continue downloading data from a >>> repository which changed its information of the release contained >>> in the repository indicating e.g a new major release. APT will fail >>> at the update command for such repositories until the change is >>> confirmed to ensure the user is prepared for the change. See also >>> apt-secure(8) for details on the concept and configuration. >>> >>> Specialist options (--allow-releaseinfo-change-field) exist to >>
Re: Debian home page -> Download link broken:
On 2023-06-11 at 09:34, Greg Wooledge wrote:
> On Sun, Jun 11, 2023 at 09:20:41AM -0400, The Wanderer wrote:
>
>> On 2023-06-11 at 09:02, Greg Wooledge wrote:
>>> Using "stable" in your sources.list is idiotic, and you should
>>> not do it. Ever.
>>>
>>> This is not a "use at your own risk" scenario, like using
>>> "testing". That's OK for people who choose to accept the
>>> responsibility.
>>>
>>> Using "stable" is just a mistake.
>>
>> I do not understand why or how. If you want to transition from one
>> stable release to the next when that "next" release is made, I
>> don't see any better option for doing so, and I don't see how
>> there's any downside to using the symbolic name 'stable' for that
>> purpose.
>
> The issue is that an upgrade to a new stable release CANNOT BE
> AUTOMATED by the tools. There are manual steps required, and these
> are specific to each release, and to each user's unique system.
While I recognize that automation is in some cases a hard problem, I
also take the position that if you have a task that has to be carried
out on a computer over and over the exact same way every time, and you
are not automating it, you are doing it wrong.
Thus, I push back - not absolutely, but fairly hard - against "cannot be
automated".
> One example of this -- among many! -- is the changing of sources.list
> line syntax across releases. This time around, we got a new section
> ("non-free-firmware") that had to be added to each line. Before that,
> there was a change to the syntax of the security.debian.org line,
> from "buster/updates" to "bullseye-security".
And rather than putting in the design, etc., work to make these things
happen automatically when they should (and not when they shouldn't), the
developers gave up and punted it to the release notes. That could be
acceptable if done rarely, but from what I remember seeing, it seems to
happen *multiple times per release*.
As I already mentioned, it's an insufficient solution - both because
people will not read the release notes before upgrading, as I mentioned,
and also because people who are tracking testing will encounter these
changes before the release notes are written. For the most part, release
notes should be for "important changes you might want to be aware of"
and/or for getting more information on the details of changes, not for
some kind of mandatory upgrade checklist.
I might even argue that for changes like the two you cite, there should
at minimum have been a tool provided (whether on a Website, or in a
Debian package, if not something run automatically) which would make the
necessary adjustments.
> And that's just an obvious and superficial change. There are
> deeper, more subtle changes as well. None of this is automatic, and
> a user who is expecting that "hey, I can just use stable and it'll
> upgrade for me every time it needs to!!!" needs to be educated.
That's not the same as the position you took above, and while I could
agree with this one, I do not agree with the other.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: Debian home page -> Download link broken:
On 2023-06-11 at 09:05, David Wright wrote: > On Sun 11 Jun 2023 at 08:12:49 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 07:50, Andrew M.A. Cater wrote: >>> If you track "testing" (something which has been deprecated for >>> a while) >> >> What? Since when? This is the first I remember having heard of >> this. >> >> Certainly the "continuously usable testing" thing seems to have not >> gone anywhere, or otherwise stalled - but that doesn't mean that >> testing isn't usable, or useful, or that tracking it is >> impractical, or anything of that nature; just that you have to >> expect that by doing so you will occasionally see things break, e.g >> during library transitions, and have to wait for those things to be >> resolved. >> >>> then you must expect that it will change very unexpectedly on a >>> release and then large changes immediately after as everything >>> else catches up with being unfrozen. >> >> Of course it will. I actually look forward to seeing that happen, >> and watching the flood of new package versions come in after a new >> release. >> >> But that doesn't mean that we should be presented with this opaque >> "this thing has changed, so we're going to refuse to update at all >> till you do something to approve that change; here's a reference to >> a man page which briefly mentions something about the technical >> details of why this happens, but doesn't explain anything about how >> to approve the change, or point to any other documentation which >> does explain that". >> >> We *are already tracking testing*, *by that name*. We *know* that >> when a new stable is released, the release codename that is in >> testing is going to change. That is *expected*. It is aggravating >> to see this prompt at all - let alone to see it again and again, >> once every few years, and have to dredge into my memory (since it's >> been a few years since the last time I needed the information) for >> where to look to find the correct incantation to actually bypass >> it. >> >> The same thing applies to those who track 'stable' by that name. >> Using the symbolic names for the releases, rather than the actual >> codenames, *is semantically different* and the tools *should treat >> it differently*. >> >> I could achieve the same practical result by using the release >> codenames, and manually editing sources.list after each release - >> but that loses out on the *convenience* factor, as well as being >> conceptually inappropriate; if you have something that has to be >> done over and over in exactly the same way every time, on a >> computer, and you are not automating it, you are Doing It Wrong. >> Using the symbolic names should make it possible to avoid those >> manual steps, and in fact it used to do just that, but it no longer >> does. >> >> As songbird said: it should all "just work". >> >> I'm actually startled that, judging from the fact that your >> responses have been centered on explaining the use of Debian >> codenames, you seem to have so completely misinterpreted the >> objection being raised here. > > It would seem very simple, the first time this happens, to configure > this in APT. I typed man apt-get (my preferred method), /release Where did you come up with the 'release' search term? I don't remember what I searched for in the apt-get man page when I first encountered this message, but whatever it was, I didn't find anything relevant. Regardless, the apt-get man page isn't the one to start with, because it's not the one the error message directs you to. The error message directs you to the apt-secure man page, which does not provide any useful information about how to resolve the error message. The error message also does not include the string 'release', in any capitalization variant, so that doesn't provide a hint for what to search for either. > and Space N three times, which showed: > > --allow-releaseinfo-change > Allow the update command to continue downloading data from a > repository which changed its information of the release contained > in the repository indicating e.g a new major release. APT will fail > at the update command for such repositories until the change is > confirmed to ensure the user is prepared for the change. See also > apt-secure(8) for details on the concept and configuration. > > Specialist options (--allow-releaseinfo-change-field) exist to > allow changes only for certain fields like origin, label, codename, > suite,
Re: Debian home page -> Download link broken:
On 2023-06-11 at 09:02, Greg Wooledge wrote: > On Sun, Jun 11, 2023 at 08:12:49AM -0400, The Wanderer wrote: > >> The same thing applies to those who track 'stable' by that name. >> Using the symbolic names for the releases, rather than the actual >> codenames, *is semantically different* and the tools *should treat >> it differently*. > > Using "stable" in your sources.list is idiotic, and you should not do > it. Ever. > > This is not a "use at your own risk" scenario, like using "testing". > That's OK for people who choose to accept the responsibility. > > Using "stable" is just a mistake. I do not understand why or how. If you want to transition from one stable release to the next when that "next" release is made, I don't see any better option for doing so, and I don't see how there's any downside to using the symbolic name 'stable' for that purpose. I also don't see how there's any difference between using the name 'stable' and using the codenames of each stable release, except in regard to the convenience factor - that is, whether the transition is picked up automatically, or whether you have to notice that the release has happened and manually modify sources.list to use the new name. I myself have sources.list entries for both 'stable' and 'testing' (as well as ancillary repositories for each, such as the -debug variants), have been running that way for a long time without related issues, and would not want to run with any other configuration. The only possible justification I can see for taking that position is the "it's dangerous to upgrade from one stable release to the next without reading the release notes first" thing, which I consider an ill-advised policy in the first place (you are *never* going to have everyone read the release notes before upgrading, any more than you are going to have people read other documentation before trying to use the thing which it documents, and it's a bad idea to design around the expectation that people will), and which in any case doesn't apply to people who are tracking testing+stable as I do. > If you're suggesting that the behavior of the tools should change in > some way -- something I am *not* advocating -- then the bext change > would be to make them *reject* any sources.list line that uses > "stable". Inform the user that the use of that label is too > dangerous, and that they must select a specific release to track. I could, maybe, perhaps, see an argument for prohibiting tracking stable, by that name, alone. However, a reject such as you are describing would also prevent the scenario I use for myself, which is effectively tracking testing with fallback to stable. If that scenario would also be worth rejecting... then that might be the final straw that confirms that Debian has in fact abandoned my use cases, and it really *is* time I found something else to move to, which would be a decidedly unhappy development. I would not necessarily object to the inclusion of a run-time *warning* about the use of such a line, especially not if there were a configuration option to disable the presentation of such a warning. I do, however, think it would be better for the tools to not require '--allow-releaseinfo-change' for repositories specified by such symbolic names - or at least to have a configuration option to not require such for that case. (My understanding is that there *is* a configuration setting to effectively enable that flag unconditionally in all cases, but I'm not sure I want to do that, and I haven't dug deep enough yet to find out whether there are more fine-grained versions of the configuration setting that might do something closer to the specific thing I want.) That said, I'm not particularly advocating for that change. What I *do* advocate, in this context, is that either the message printed by apt-get when it sees the mismatch should be changed to point to a document which explains how to approve the change, or the document to which it points - apt-secure(8) - should be changed to explain that. It is *boggling* that we have reached, if I'm not mistaken, now at least the *third* consecutive Debian release with this uninformative and unhelpful "see here for more" message. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian home page -> Download link broken:
On 2023-06-11 at 07:50, Andrew M.A. Cater wrote: > On Sun, Jun 11, 2023 at 05:58:50AM -0400, songbird wrote: > >> Tixy wrote: >>> Or maybe the wiki page should be deleted, or just say go RTFM, >>> i.e. read the release notes for the release you want to upgrade >>> to. >> >> except that is a misconception for those who are running testing. >> we're not upgrading to a new release. > Hi Songbird and all, > > I may go and have a crack at editing the wiki pages in a few > minutes. Hint: Anybody with a wiki account can edit the wiki - it > really is a wiki. > > Release names and codenames: > > This is a subject that has been fairly well explained over the > years. Debian 1.0 never actually got released - someone took > pre-release links and rebranded them as "Debian 1.0" for a CD > release. At that time, Debian took on the idea of release names to > stop this happening again. > > If you follow the release name in your /etc/apt/sources.list it will > follow a release from testing -> stable -> oldstable -> > oldoldstable. > > If you track "testing" (something which has been deprecated for a > while) What? Since when? This is the first I remember having heard of this. Certainly the "continuously usable testing" thing seems to have not gone anywhere, or otherwise stalled - but that doesn't mean that testing isn't usable, or useful, or that tracking it is impractical, or anything of that nature; just that you have to expect that by doing so you will occasionally see things break, e.g during library transitions, and have to wait for those things to be resolved. > then you must expect that it will change very unexpectedly on a > release and then large changes immediately after as everything else > catches up with being unfrozen. Of course it will. I actually look forward to seeing that happen, and watching the flood of new package versions come in after a new release. But that doesn't mean that we should be presented with this opaque "this thing has changed, so we're going to refuse to update at all till you do something to approve that change; here's a reference to a man page which briefly mentions something about the technical details of why this happens, but doesn't explain anything about how to approve the change, or point to any other documentation which does explain that". We *are already tracking testing*, *by that name*. We *know* that when a new stable is released, the release codename that is in testing is going to change. That is *expected*. It is aggravating to see this prompt at all - let alone to see it again and again, once every few years, and have to dredge into my memory (since it's been a few years since the last time I needed the information) for where to look to find the correct incantation to actually bypass it. The same thing applies to those who track 'stable' by that name. Using the symbolic names for the releases, rather than the actual codenames, *is semantically different* and the tools *should treat it differently*. I could achieve the same practical result by using the release codenames, and manually editing sources.list after each release - but that loses out on the *convenience* factor, as well as being conceptually inappropriate; if you have something that has to be done over and over in exactly the same way every time, on a computer, and you are not automating it, you are Doing It Wrong. Using the symbolic names should make it possible to avoid those manual steps, and in fact it used to do just that, but it no longer does. As songbird said: it should all "just work". I'm actually startled that, judging from the fact that your responses have been centered on explaining the use of Debian codenames, you seem to have so completely misinterpreted the objection being raised here. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: "dpkg-reconfigure" dash no longer works
On 2023-06-09 at 12:00, Charles Curley wrote: > On Fri, 9 Jun 2023 13:38:25 + > S M wrote: > >> I noticed on a newly installed system with Debian 12 that >> dpkg-reconfigure no longer allows to switch the /bin/sh symlink from >> dash to bash. > > You can still change it manually (rm ; ln -s). Or just 'ln -sf', to do it in something closer to an atomic fashion. Except that, since (at least from what I can see on a quick check) the /bin/sh symlink appears to be shipped explicitly in the dash package, next time that package gets upgraded the symlink will probably be overwritten with one pointing back to dash again. If the system is smart enough to not replace a sysadmin-edited symlink during package upgrade, then that wouldn't happen - but I'd honestly expect that it would, since otherwise if a symlink got messed up and broke things, reinstalling the package it came from wouldn't be guaranteed to fix those things. Of course, there's still the question of the *reason* why this change was made and why using anything but dash for /bin/sh is now considered no longer supported. I don't have any explanation for that, and until the maintainers actually give one, neither do the rest of us - but in the absence of one, it's hard to be sure that pointing the symlink to /bin/bash won't break something. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Firefox resource utilization (was Re: A case for supporting antiquated hardware, was Re: A hypervisor for a headless server?)
On 2023-06-03 at 07:18, Max Nikulin wrote: > On 03/06/2023 17:40, The Wanderer wrote: > >> Hey, now. I once had a Firefox session (with "restore tabs from >> previous session" enabled, and about six-to-eight windows) with >> 5,190 open tabs, and that computer only had 24GB of RAM. > > Modern browsers supports "unloaded" tabs, so most of your tabs likely > were similar to bookmarks with page resources not loaded to RAM. That feature was, AFAIK, first introduced in the BarTab addon which I mentioned. So, yes, and although in hindsight I didn't state it explicitly, I intended to convey that by mentioning that addon. > P.S. Perhaps in future tabs as UI element in browsers will be merged > with bookmarks and browsing history. The only prerequisite to better > save state of scroll position and partially filled forms. I'm not sure quite what you're envisioning, but one reason why I keep so many open tabs rather than using e.g. bookmarks instead is because I want to be able to preserve forward/back history within each tab; I don't know of any other feature that enables doing that. I also can't think of another UI paradigm for interfacing with such a setup that would work any better than tabs do. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Firefox resource utilization (was Re: A case for supporting antiquated hardware, was Re: A hypervisor for a headless server?)
On 2023-06-03 at 01:41, Nicholas Geovanis wrote: > On Fri, Jun 2, 2023, 6:10 PM Bret Busby wrote: >> This computer, with 128GB RAM, I regard as far superior to an i9 >> computer with 8GB RAM. >> Refurbished computer profile (with 128GB RAM (that runs about 200 >> windows of Firefox (I have one saved session, with 229 windows, >> and about 3200 tabs), while viewing movies (I also have about 10 >> movies open at present, in Celluloid and SMPlayer), although, at >> present, I have only about 127 Firefox windows open, with 1689 >> tabs): > > Holy cow! :-) No wonder you have 128GB RAM. You will need that much > for that much Firefox. It's a peeve of mine how resource intensive it > is for a browser compared to the competition. Hey, now. I once had a Firefox session (with "restore tabs from previous session" enabled, and about six-to-eight windows) with 5,190 open tabs, and that computer only had 24GB of RAM. ...And it used BarTab, or rather a variant that I maintained myself after the original maintainer decided getting a small subset of that addon's functionality integrated into the upstream browser was sufficient. I'm doing much better now; I've got only 1,491 open tabs, split across eight browser windows, on a machine with 64GB of RAM. (I think I had it down under 1,000 total tabs at one point. I still hope to get it down to a range of 200-500 total tabs; I don't think I'll realistically be comfortable running with fewer than that, given what I use them for.) And all of this is with older Firefox versions, which are considerably more resource-intensive in my experience than newer Firefox is. I may dislike a lot of things about where Mozilla has taken Firefox, but I do prefer to see it criticized for the faults it actually has. Resource-intensive it may be, but unless extra windows increase resource usage far more than extra tabs do, you don't need anything *close* to 128GB for ~1700 Firefox tabs in ~128 Firefox windows. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Stable and testing together?
On 2023-05-13 at 05:28, Hans wrote: > Hi folks, > > there is a question, which is in my mind for many years. > > Is there any reason, why not using oldstable, stable and testing > together? Others have cited reasons why not, and those reasons are valid. Despite that, this (or a subset, since I have no interest in oldstable) is exactly what I run. It is effectively running testing, with packages in stable available as a fallback in the event that I find the need to install something that has been (hopefully temporarily) removed from testing. I tend to dist-upgrade against this on a weekly basis during most of the development cycle of a Debian release, and on a daily basis (or more) during the first few/several weeks after a release is made. I have definitely encountered bugs in the course of doing this, and have had to work around or otherwise resolve them. But so far, this has been the course of fewest overall problems for me, for quite a number of years now. I don't think I'd choose to run a "daily driver" Debian system against anything else. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: disk usage for /usr/lib on bullseye
On 2023-05-02 at 10:28, Bret Busby wrote: > On 2/5/23 20:23, Michel Verdier wrote: > >> Le 2 mai 2023 Bret Busby a écrit : >> >>> I expect that, by context, running >>> apt purge >>> without the restriction specifying particular package, will apply >>> apt purge >>> to all installed packages, according to what purge does, in relation to >>> packages. >> >> But as "apt purge " remove this package and remove configuration >> for this package, I hope that "apt purge" will not remove "all installed >> packages". Personnally I will not test it... >> > I believe that this is a case of a problem with having different primary > languages (me, English, the above poster, French), with things getting > "lost in translation". > > I did not mean that purge will remove all installed languages; as > according to my last previous post in this thread (I think it was my > last previous post - I am not sure); > apt purge > apparently removes obsolete configuration files (orphaned configuration > files - that would have been associated with only packages that have > been removed), and, so, where a particular package is specified as an > argument to the command, all obsolete configuration files associated > with the package, will be removed, and, where no package is specified as > an argument to the command, all obsolete configuration files for "all > installed packages", will be removed. > > No suggestion has been made, insofar as I am aware, other than in the > above post, that using > apt purge > will remove all installed packages. I continue to be bewildered that the idea that it will do *anything* has even come up. My understanding, for more than a decade now, has been (as it continues to be) that: 'apt-get remove packagename' will remove the package, if it's installed, but not remove its config files. 'apt-get purge packagename' will remove the package, if it's installed, and also remove its config files, if they are present. 'apt-get remove' with no 'packagename' argument is a syntax error. 'apt-get purge' with no 'packagename' argument is a syntax error. The command 'apt' is newer than that, I think, but I see no reason to think that these verbs would behave any differently between the two commands. Aside from some possibly-unclear wording in the man page(s), where is the idea that running either of these verbs with no package-name argument will make them apply to *all installed packages* coming from? That would be an *insane* design decision, IMO, and it seems bizarre that anyone is even coming up with the idea in the first place, let alone that it's being given any credit. > I think that, to remove all installed packages, a system administrator, > from the superuser level, needs to run something like > rm -r / > (assuming that the /bin and /sbin (etc, etc, etc) directories are within > the / partition, and, not in partitions separate to the / partition) > - the use of which command, I do not recommend. That would remove far more than all installed packages; it would also remove all files not included in any package, and potentially also all files on any mounted network shares, et cetera. IIRC, there are packages which the system will refuse to remove, unless an appropriate overriding action is taken. It may now be the case that there are packages which the system will refuse to remove entirely, without offering any means to override the refusal. If that were not the case, removing all installed packages could probably be done by something like apt-get remove $(apt-mark showmanual) $(apt-mark showauto) except that A: the resulting list of packages would probably be too long for a single command line, and B: one of the packages which this would try to remove (probably fairly early on, since they'd be listed in alphabetical order) would be the 'apt' package itself, which contains both 'apt-mark' and 'apt-get', and so the process would probably break after that. It's a pointless thing to discuss, in any case, since I have been unable to think of essentially any reason why anyone would ever want to do any such thing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: I need help with my var partition.
On 2023-05-01 at 21:51, Maureen L Thomas wrote: > Unfortunately I cannot install anything. I used the command line and > the app but neither of them will work. I suspect that if you don't have the various directories under /var/, you may not be able to use apt or aptitude or synaptic or the like, but dpkg (in the form of 'dpkg -i /path/to/filename.deb') may still work. If it doesn't, the only fallbacks that I can think of that would be *more* likely to work - short of reinstalling Debian, anyway - involve carefully extracting the .deb's contents into the correct root path, and running any necessary follow-on scripts, *by hand*. And that would be daunting even to me, though I understand that it's certainly possible. > I have no idea what to do next. I used su and sudo first. It just > keeps saying it cannot connect with the base from which I get > updates, etc. I used the reinstall on brasero and it just said that > it was up to date. I am so confused. This description seems to suggest that you're using a tool which is trying to download the .deb file from a remote location. Those tools are fairly likely to have problems if the directories under /var/ don't exist. Instead, I suggest that you try: $ su - # dpkg -i /var/cache/apt/archives/base-files_12_amd64.deb (Or whatever the version number and architecture of your base-files package may be; that's the oldest one I have on hand myself, from August of 2021. You should probably be able to tab-complete the filename from before the first underscore, but that depends on how your system is set up.) dpkg should, I think, have fewer dependencies on directory structure (et cetera) than anything APT-based will have. It still might not be few *enough*, but it's worth a shot. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: I need help with my var partition.
On 2023-04-28 at 20:46, Jeremy Ardley wrote: > On 29/4/23 08:25, Maureen L Thomas wrote: > >> I am 72 and have forgotten a few things. I looked up debian/var and >> was told I could delete /var/log/ >> >> and /var/tmp/ and /var/cores/. I'd guess that this was *probably* meant as a direction to delete *files from inside* those directories. Deleting the directories themselves, or even deleting their contents wholesale, can - as you've discovered - create a problematic circumstance. >> I left cores alone and deleted the other two. Now I cannot burn a >> backup, download files and even go to web sites from my nord vpn >> which was working great until I deleted the above files. I really >> want to upgrade to debian 11. I am using debian 10, on a Lonovo all >> in one and have had no problems. I followed the directions for var >> that I found and now have a screwed up machine. Is there any help >> available. I was thinking of upgrading online but don't want to >> loose my data. Please help this old lady. >> >> > Deleting /var/log etc is at best unhelpful. > > I can't think of any procedure that would require deleting those > directories. Perhaps someone was fooling with you? > > Without knowing what else you have done or why, it's probably a good > idea to recreate the directories > > cd /var > > mkdir log > > mkdir tmp That won't necessarily bring back the correct directory permissions, or any needed subdirectory structure under these two locations. I'm not *positive* that this won't break anything, but I think the safest thing to do would probably be to reinstall the 'base-files' package, which can *probably* still be done - even on a system with those directories missing - with 'dpkg -i' from the copy in /var/cache/apt/archives/. That should, I think, bring back both directories with any needed permissions. It will not, however, re-create any subdirectories (e.g. under /var/log/) which were created by other packages; for that, you'd have to reinstall those packages as well. Given that one of the directories on my own system is /var/log/apt/, it's not impossible that much of the package-management system may not work (fully) correctly until you've identified and reinstalled the correct packages. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: sudo and echo
On 2023-04-28 at 20:36, Greg Wooledge wrote: > On Fri, Apr 28, 2023 at 08:00:02PM -0400, The Wanderer wrote: > >> I would suspect that >> >> $ sudo 'echo 123 > /root/123.txt' >> >> would produce the effect you're after, but as I don't have sudo >> installed, cannot verify that myself. > > No, that won't work. It'll try to execute a program named 'echo 123 > > /root/123.txt' which is really, really unlikely to exist in your > current working directory. That was the other possibility, the existence of which which was the reason why I couched this in terms so far from certainty. The need to invoke a shell around them was also a possibility I considered, but I didn't want to rewrite the post three more times trying to express that too without also adding so much more complexity as to make the thing unreadable. You managed it all much more concisely and helpfully than I had done. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: sudo and echo
On 2023-04-28 at 19:52, cor...@free.fr wrote: > Hello list, > > When I run this command: > > $ sudo echo 123 > /root/123.txt > > It tells me "permission rejected". > > Why this sudo can't get success? If I'm not very much mistaken: because redirection like that is (as I understand matters) processed by the currently-active shell, not by the environment that will be created inside the sudo invocation. What this is almost certainly doing is passing 'echo' and '123' to sudo, and telling the *current* shell to redirect the output of 'sudo echo 123' into /root/123.txt. If the current shell process does not have permission to write to that location, then you will get that error. I would suspect that $ sudo 'echo 123 > /root/123.txt' would produce the effect you're after, but as I don't have sudo installed, cannot verify that myself. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: MariaDB Server is not installing on Debian 12
On 2023-04-21 at 14:11, Cosmin Humeniuc wrote: > I have the same problem of not being able to install mariadb-server > 1:10.11.2-1. The error is the same - a failed attempt to stop > mariadb.service or mysql.service. > > In my case, there is no service running for either of them, so I have > nothing to stop. I also checked, and there's no mariadb.preinst file in > /var/lib/dpkg/info. > > However, I started from these lines in the output: > > Errors were encountered while processing: > > /var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb > > and I used dpkg-deb to look in that package file. DEBIAN/preinst had a > `stop_server()` function that was trying to stop existing servers based > on the result of: > > pgrep -x --nslist pid --ns $$ "mysqld|mariadbd" > > (at line 31). I executed that in a shell and I did get a result - only > it wasn't for a running server, but for a standalone process: > > pgrep -x --nslist pid --ns $$ "mysqld|mariadbd" > > 1939 > > > ps aux | grep 1939 > > cosmin 1939 0.0 1.2 2439604 204892 ? Sl 19:22 0:02 > /usr/sbin/mysqld > --defaults-file=/home/cosmin/.local/share/akonadi/mysql.conf > --datadir=/home/cosmin/.local/share/akonadi/db_data/ > --socket=/run/user/1000/akonadi/mysql.socket > --pid-file=/run/user/1000/akonadi/mysql.pid How is that not a server? /usr/sbin/mysqld is the server binary; that looks like an instance of the server, run by (what I'm presuming is) an ordinary user rather than by e.g. the 'mysql' account that is used to run the 'system-wide' instance(s?) of that server. I could just be blind or ignorant, but I can't see any reason offhand why that process wouldn't be expected to need to be stopped in just the same way as those running under other user IDs. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Apt sources.list
On 2023-04-15 at 19:11, Greg Wooledge wrote: > On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote: > >> In case you wish to obscure what software you *install*, but need >> not conceal the software you *download*: >> >> Step one: Make a list of the packages you want, and then augment >> it with as many plausible alternatives and red herrings as you >> like. >> >> Step two: $ apt-get -d install >> >> This downloads the packages only, so you can download packages you >> will *not* install, along with ones you will. Then install the >> proper subset you want installed, without the '-d' option. > > I'm at a loss as to what threat model this is supposed to protect > against. My guess is that it's supposed to make it harder for people to guess what exploits your computer may be vulnerable to, by obfuscating which of the various packages you downloaded are actually installed and therefore potentially in use. > Now, personally I don't feel this is a threat model that I need to > worry about. I just use plain old http sources at home, and if > "They" learn that I've downloaded rxvt-unicode and mutt, well, good > for Them. My understanding is that mandating HTTPS for all connections is supposed to make it so that those who might be watching can't treat the choice by the user to connect via HTTPS as a sign that the user has something to hide, and therefore is worth observing more closely. I seem to remember having seen suggestions that some regimes might even prohibit the use of HTTPS entirely, so as to ensure that they can spy on their subjects' connections, and that such a prohibition would be less practical for them to impose if everything requires HTTPS. I'm not sure about the real-world basis for that, however. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On 2023-04-14 at 19:17, Brian wrote: > On Fri 14 Apr 2023 at 19:06:08 -0400, The Wanderer wrote: > >> On 2023-04-14 at 18:52, Brian wrote: >>> The EPSON ET M 1120 doesn't exist. Do we have to guess its >>> correct name as well as any other relevant information? >> >> When I searched for >> >> Epson ET M 1120 >> >> I got a suggestion that I may have meant "M1120" instead of the >> last two search terms, and hits for the "Epson EcoTank ET M1120" >> and/or "Epson EcoTank M1120", which look to be different names for >> the same model and to be a fairly clear match. >> >> While, yes, specifying the exact name clearly would be preferable, >> this is far from unreasonably difficult to figure out. > > I decided to take your signature as a template for my original > response :). I can respect that! >>> I haven't a clue what you are going on about here. Shift-L in >>> mutt was used at this end. >> >> Your replies to the OP have been fine, AFAIK. The OP's message was >> itself a reply, as can be seen by looking at its headers >> (In-Reply-To: and References:), but was otherwise presented as if >> it had been the start of a new thread; that is not fine, because it >> hides the "new thread" inside of the existing one, at least for >> anyone using a threaded view of the list of messages. > > That's an issue for the OP, not me. Certainly. I was meaning that bullet-point item as an addendum to the list you provided (which I understand to have been aimed at the OP), not as something directed at you. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On 2023-04-14 at 18:52, Brian wrote: > On Fri 14 Apr 2023 at 18:22:09 -0400, The Wanderer wrote: > >> On 2023-04-14 at 18:10, Brian wrote: >> > You could consider: >> > >> > * Stating the Debain OS being used. >> > * Giving the printer make and model. >> >> The make *was* stated: Epson. >> >> The model may also have been stated, albeig only in the Subject line: ET >> M1120. From a bit of Googling, the "ET" appears to stand for "EcoTank". > > The EPSON ET M 1120 doesn't exist. Do we have to guess its correct name as > well > as any other relevant information? When I searched for Epson ET M 1120 I got a suggestion that I may have meant "M1120" instead of the last two search terms, and hits for the "Epson EcoTank ET M1120" and/or "Epson EcoTank M1120", which look to be different names for the same model and to be a fairly clear match. While, yes, specifying the exact name clearly would be preferable, this is far from unreasonably difficult to figure out. >> > * Specifying the connection method. USB. Network. >> > * Giving the exact error message and where it came from. >> >> Also: >> >> * Starting a new thread to discuss the matter, rather than replying >> to an existing message deep in an existing thread, deleting the >> body, and changing the Subject line before sending. >> >> (This question, and its replies, are appearing as responses to a >> mail from Michael Stone in the 'update-initramfs' thread.) > > I haven't a clue what you are going on about here. Shift-L in mutt > was used at this end. Your replies to the OP have been fine, AFAIK. The OP's message was itself a reply, as can be seen by looking at its headers (In-Reply-To: and References:), but was otherwise presented as if it had been the start of a new thread; that is not fine, because it hides the "new thread" inside of the existing one, at least for anyone using a threaded view of the list of messages. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On 2023-04-14 at 18:10, Brian wrote: > On Fri 14 Apr 2023 at 14:40:33 +, Schwibinger Michael wrote: > >> Good afternoon. >> The new printer is not working. >> EPSON is saying >> You cant use EPSON with Linux. >> >> Is this true? > > You could consider: > > * Stating the Debain OS being used. > * Giving the printer make and model. The make *was* stated: Epson. The model may also have been stated, albeig only in the Subject line: ET M1120. From a bit of Googling, the "ET" appears to stand for "EcoTank". > * Specifying the connection method. USB. Network. > * Giving the exact error message and where it came from. Also: * Starting a new thread to discuss the matter, rather than replying to an existing message deep in an existing thread, deleting the body, and changing the Subject line before sending. (This question, and its replies, are appearing as responses to a mail from Michael Stone in the 'update-initramfs' thread.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian Stretch : X server won't start after update
On 2023-04-14 at 15:53, davidson wrote: > On Fri, 14 Apr 2023 Brian wrote: > >> On Fri 14 Apr 2023 at 18:48:06 +0200, Bernard wrote: >> >>> Hi to Everyone, >>> >>> I am writing from my laptop on Ubuntu, but the problem I have is >>> with my Desktop running Debian Stretch. Having unfortunately >>> Okayed a proposal for an update (which I rarely do…), upon >>> restarting the system fails to launch X server. >> >> I thought stretch is unsupported by Debian. Where did the update >> come from? > > I speculate that the OP's sources.list identifies the desired > distribution by a temporally relative suite name --say, "stable" or > "oldstable"-- instead of the temporally absolute release codename > "stretch". Alternately, perhaps the OP "okay[s] a proposal for an update" *so* rarely that there was actually still one pending from when stretch was still getting support. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: update-initramfs
On 2023-04-12 at 07:44, Michel Verdier wrote: > Le 12 avril 2023 The Wanderer a écrit : > >> Without anything more, wouldn't that just result in an extra >> GRUB-menu entry pointing to the same copy of the kernel/etc.? > > Of course he can change menuentry to point to another kernel/initram From what I understand matters, the problem is that after he creates the copy of the initrd, update-initramfs (as run by update-grub) fails, because the underlying files which it thinks would be needed by an initrd with the filename that the copy has don't exist. >> As I think I understand matters, the goal is to have a duplicate >> copy of the kernel/etc. *and* a separate GRUB menu entry pointing >> to it, so that if something blows away or otherwise messes up the >> original the duplicate is still around to serve as a fallback. > > Yes if he points menuentry to the backup he got this fallback. The question would therefore be how to have the backup copy without resulting in this update-initramfs failure happening. About the only possibility I can think of would be to *also* copy the respective underlying files, so that they are available under the name update-initramfs expects to see. That would probably make the backup - and the process of creating it - noticeably more unwieldy, however. And it's entirely possible that there's some aspect of the process I'm not seeing which would mean that that wouldn't work. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: update-initramfs
On 2023-04-11 at 22:30, Michel Verdier wrote: > Le 11 avril 2023 davidson a écrit : >> I believe the OP just wants an extra entry in his grub menu that >> will boot a redundant copy of his latest working kernel. (But that >> is only my understanding, which might be wrong. OP can speak for >> himself on this point.) > > Ok to cover grub menu you just have to had it in /etc/grub.d. You > simply copy a block menuentry from /boot/grub/grub.cfg and put it in > something like /etc/grub.d/40_custom. In the copy you can change > kernel params, etc. update-grub will include it in generated > grub.cfg. Without anything more, wouldn't that just result in an extra GRUB-menu entry pointing to the same copy of the kernel/etc.? As I think I understand matters, the goal is to have a duplicate copy of the kernel/etc. *and* a separate GRUB menu entry pointing to it, so that if something blows away or otherwise messes up the original the duplicate is still around to serve as a fallback. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Mailing list usage questions
On 2023-04-11 at 16:22, zithro wrote: > Hello all, > > I have two questions about the Debians ML usage. > > 1. when subscribing, the confirmation message says "By default, copies > of your own submissions will be returned." > What is the meaning of "default" and "returned" here ? > I understand that I should get my own replies. But I never get them. Are you A: running your own mail system, or B: using an externally-hosted mail service, either Ba: directly or Bb: under a personal domain? Some mail services apparently treat this "discard incoming messages that look like duplicates of ones you already have a copy of" behavior as a feature; Gmail is the best-known example. That has problems when (as with this mailing list) the incoming copy is not identical to the one that was sent, even though it has the same Message-ID, but AFAIK they don't seem to care. If you're using an external mail service which does have that behavior, then that would probably explain what you're seeing. If you aren't using an external mail service, or are using one which doesn't have that behavior (i.e., if e.g. messages sent to other mailing lists to which you are subscribed do come back to you), then there's probably a different problem and it would be warranted to dig deeper. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: should CLI have a nice UI today?
On 2023-03-29 at 10:09, to...@tuxteam.de wrote: > On Wed, Mar 29, 2023 at 09:51:13AM -0400, Stefan Monnier wrote: > >>> I think you are being too harsh here. Such a question may come >>> genuinely from someone who hasn't experienced the power of the >>> CLI, which, once you've taken the firs step gently takes you to >>> small one-liners, little loops and bigger and bigger programs. >>> >>> It has this seamless "growth path" which helps and entices its >>> users to get better, something I miss from most GUIs, which >>> rather tend to degrade the user to a click machine. I don't know >>> whether this is inherent to GUIs or just the current "social >>> convention" underlying actual GUIs. >> >> I think it's the same underlying reasons why programming languages >> are almost universally represented as text: maybe it's just because >> of habit or "social convention", but I think there's something more >> fundamental at play, which make it very hard to make non-textual >> programming languages (and maybe even formal systems in general). > > Perhaps roughly 3k to 4k years of storing, transmitting and > retrieving information in written form have a part in it. > > It may be a social convention, but by now it runs so deep that I'm > convinced you'll find epigenetic traces of it in us humans. I think it's plausible/probable that it's not so much about the format itself, but about the data/meaning/information attached to that format. Text has much more *nuance* and *detail* attached to it than any non-text-based programming structure I've ever run across, while also having more *formality* and *precision* attached to it than e.g. spoken-word conversations (which have a lot more nuance, because of the added information channels of tone and inflection and the like). If you can contrive another format for representing the user's intention that enables comparable or greater amounts of expressiveness, while not sacrificing much if any precision or rigor, I suspect that that format might be able to equal or surpass text for programming, etc., purposes. Good luck with doing that, though; if such a thing were practical, it would very likely have been invented long since. Unless it only becomes practical with a technology that's only become available relatively recently, but unless e.g. the recent forays into "AI" represent such a thing, I'm not sure what candidates for such a thing there might be. (And even those "AI"s are interacting with people through text.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: How do I specify a custom apt dependency between kernel image and its headers?
On 2023-03-27 at 20:03, Ram Ramesh wrote: > I have nvdia card that requires binary driver to work in my system. > Xorg is unable display anything with free driver. Since nvidia-driver > has to be built for each kernel install, I need to install headers > also. This seem to work automatically for any standard kernel release > in bullseye. However when I install newer kernel from backport, apt > does not install headers automatically. How do I tie the install of > linux-image to linux-header so that I cannot install image without > the headers. If I understand you correctly, you want to set it up so that for every package pair linux-image- linux-headers- attempting to install the former results in also installing the latter? And you want this to apply not just for a specific version number, but for every version number, including ones that haven't come out yet? Just off the top of my head, I don't think there's any way to accomplish that. The only possible avenue I can think of for adding an effective dependency to a package - without modifying its source and rebuilding it - is by making a custom metapackage (with custom dependencies) via equivs, and I don't think there's a way to do that with enough dynamic adjustment for this scenario. I think you'll probably need to just deal with specifying the install of the headers package explicitly when you install the image package. Unless the image package is coming in automatically, by dependency from e.g. the generic linux-image or linux-image- package, when you upgrade that package? In that case you might consider also installing the generic linux-headers (or linux-headers-) package, and upgrading both of them at once, so that when there's a new image package there will also be a new headers package at the same time. That's a workaround, though, and doesn't actually do quite exactly what you asked for. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: package name just before power off
On 2023-03-23 at 10:50, John wrote: > I get an error message which is absolutely the last thing before > poweroff that is NOT ever reported in kern.log nor by dmesg. Typically, the very last messages from before power-off would be expected to come from the kernel, as it should be the last thing still running. > It reads like this: > 48.255417 DMAR: DRHD: handling fault status reg 2 > 48.255457 DMR: [DMA Read] request device [00:17.0] PASID fault addr > aboe9000 [fault reason 06] PTE read access is not set > 48.27 reboot: Power down > > What pack age would this be in so I can file a bug? Googling for parts of these messages find multiple bug reports on kernel.org (I've seen at least one from 2016 and one from 2019, both apparently about the relevant messages appearing in floods), so that seems to confirm that these messages are coming from there. It will probably be relevant what kernel you're running. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Microcode bug problem?
On 2023-03-19 at 14:00, Jesper Dybdal wrote: > I am planning to upgrade from Buster to Bullseye, and trying to prepare > for any problems. > > The release notes say >> The intel-microcode package currently in bullseye and buster-security >> (see DSA-4934-1 (https: >> //www.debian.org/security/2021/dsa-4934)) is known to contain two >> significant bugs. For >> some CoffeeLake CPUs this update may break network interfaces >> (https://github.com/intel/ >> Intel-Linux-Processor-Microcode-Data-Files/issues/56) that use >> firmware-iwlwifi, >> and for some Skylake R0/D0 CPUs on systems using a very outdated >> firmware/BIOS, the system may >> hang on boot >> (https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/ >> issues/31). > > I have no idea whether my old processor is a "CoffeeLake" or a "Skylake" > or something else. It is a pc that I bought in 2008, I think (and still > working just fine). > > /proc/cpuinfo says: >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 23 >> model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz According to a bit of Googling, the Core 2 Duo E8400 is from the microarchitecture codenamed Wolfdale. According to https://en.wikipedia.org/wiki/List_of_Intel_CPU_microarchitectures, Wolfdale is the codename for the desktop version of what might be considered "generation 0", prior to the "Core i" series of CPU product names, and was released in 2007. According to that same page, Skylake was generation 6, and was released in 2015. According to that same page, Coffee Lake was part of generations 8 and 9, and was released in 2017. > Do I need to worry about those microcode bugs? Based on the above: no. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: mount new block deivce in existing dir
On 2023-03-05 at 14:11, Ken Young wrote: > Hello > > My vps has limited volume for /. You can see it as follows. > > root@nxacloud-bloghost:~# lsb_release -cd > > Description: Debian GNU/Linux 11 (bullseye) > > Codename: bullseye > > > root@nxacloud-bloghost:~# df -h > > Filesystem Size Used Avail Use% Mounted on > > udev472M 0 472M 0% /dev > > tmpfs98M 496K 98M 1% /run > > /dev/vda1 9.7G 1.5G 7.9G 16% / > ... > > > So I want to add a block device /dev/vdb and fdisk/format it and mount it > as /home dir. > Since /home already exists (even have data in this path). can I mount it > without problem? If you mount the new volume over the existing directory, then attempts to access that directory will see the contents of the new volume, not the pre-existing contents of the directory. I'm not familiar with what constraints being in a VPS environment may apply to this. In order to achieve what you want, in a non-VPS environment, you would need to: * Create and format your new filesystem. * Log in as a user which does not need the contents of /home in order to function. (I don't know what the constraints of your VPS are; this can typically be done by logging in as root, but depending on the system configuration there might be other factors.) * Move the contents of /home (but not /home itself!) into a new, temporary directory. * Mount the new volume over /home. (And make sure that fstab, etc., are configured to perform that mount automatically in the future.) * Move the contents of the temporary directory back into place in /home. At that point, if everything was done correctly and no special permissions considerations apply, it should be possible and safe to log back in as an ordinary user and have things work correctly. Caveat emptor; this is not a terribly esoteric operation, but if it is not carried out quite correctly, it is not one entirely without risk. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: solution to / full
On 2023-03-01 at 09:15, Jochen Spieker wrote:
> lina:
>
>> My / is almost full.
>>
>> # df -h
>> Filesystem Size Used Avail Use% Mounted on
>> udev126G 0 126G 0% /dev
>> tmpfs26G 2.3M 26G 1% /run
>> /dev/nvme0n1p2 23G 21G 966M 96% /
>> tmpfs 126G 15M 126G 1% /dev/shm
>> tmpfs 5.0M 4.0K 5.0M 1% /run/lock
>> /dev/nvme0n1p6 267M 83M 166M 34% /boot
>> /dev/nvme0n1p1 511M 5.8M 506M 2% /boot/efi
>> /dev/nvme0n1p3 9.1G 3.2G 5.5G 37% /var
>> /dev/nvme0n1p5 1.8G 14M 1.7G 1% /tmp
>> /dev/nvme0n1p7 630G 116G 482G 20% /home
>
> This is a good example why it often makes sense to use LVM even on a
> private system. With LVM you could have allocated only 20% of space
> where you actually need it and resize filesystems on-demand (and
> online). But that does not help you now, sorry.
>
>> I have done some purging already.
>> :/usr# du -sh *
>> 742M bin
>> 4.0K games
>> 260M include
>> 8.1G lib
>> 36M lib32
>> 4.0K lib64
>> 140M libexec
>> 33M libx32
>> 3.4G local
>> 53M sbin
>> 4.6G share
>> 215M src
>
> /usr/local might be worth a look. You probably have some stuff there
> that you put in manually.
>
> The program dpigs from the package debian-goodies can help you find the
> biggest debian packages you have installed. Of course you need to check
> yourself whether you need them.
It might also be worth having a look at the output of
# du -hx --max=1 /
rather than just looking at /usr alone. The '-x' will mean it won't
cross the boundaries into the other filesystems, so you'll still just be
looking at what's on / ; '--max=1' means it'll report one directory
level deep from the items you specified on the command line ('--max=0'
is equivalent to '-s').
You might even find benefit from repeating that same command with /usr,
or with any other directory that specifically looks to be bigger than
expected, to find out what part of it is taking up so much of the space.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: Remove route '169.254.0.0/16 dev ovs-system'
On 2023-02-19 at 11:21, Geert Stappers wrote: > Hi, > > Having installed package openvswitch-switch and doing `ip route` I do get > > 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004 > > > What can be done to prevent that "zeroconf" > configures interface `ovs-system`? One angle I haven't seen suggested thus far, in the discussion of avahi et cetera: a bit of 'apt-file search' and 'apt-cache search' seems to suggest that ovs-system may be related to the OpenVSwitch stack (and a bit of Googling seems to back that up). You might see whether you have any packages installed that match "ovs", "ovn", "openvswitch", or similar, and if so either remove them (if you don't need them) or investigate the configuration settings they may offer. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: versions comparison
On 2023-02-17 at 20:48, Greg Wooledge wrote:
> On Fri, Feb 17, 2023 at 07:42:24PM -0600, John Hasler wrote:
>
>> Also, while Debian uses a sane, consistent version numbering system it
>> is not safe to make assumptions about what non-Debian developers do.
>
> The best thing I can say about Debian's version strings is that they
> are documented.
>
> unicorn:~$ grep ^Version:
> /var/lib/apt/lists/ftp.us.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
> | awk '{print length($0), $0}' | sort -rn | sed 's/.* //' | head
> 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1.1
> 0.0~git20201031.beca652+really.git20200323.1b35463-2
> 0.0~git20201031.beca652+really.git20200323.1b35463-2
> 7.3.3+dfsg1-1+0.0~git20210225.1e7ef9e+dfsg-4
> 3.0.7+git.20130130.97b34ece.REALLY.1.0.3-2.1
> 0.16.1+20180422git6becd92d7fce3fc411d7c-4+b3
> 6.1.0~1.1.0+~2.0.1~ds+~6.1.0+~0~20180821-1
> 2.0.1~1.1.0+~2.0.1~ds+~6.1.0+~0~20180821-1
> 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1
> 1.1.0~1.1.0+~2.0.1~ds+~6.1.0+~0~20180821-1
>
> Every single piece of that line noise has some meaning... to someone. ;-)
It's really fairly straightforward when you know the pieces involved.
I'm not previously familiar with any of these specific version numbers,
but I could explain exactly what each part of any given one of them
means, if there were need to do so.
(I tried to write up a general explanation that would cover all of them,
but it was starting to develop too many moving parts and sub-clauses for
that to seem to be worthwhile in the immediate context.)
These versions also don't even display one key component of Debian
version numbers that isn't found in versions elsewhere: the epoch.
That's a number which appears at the start of the version, is delimited
from the rest of the version by a colon, and when omitted is
automatically treated as being 0. It's used to allow for the case of a
version-numbering scheme changing, where the new version would not
otherwise sort as greater than the old - e.g., if the old version was
date-based (20230217, for a version referencing today's date) and the
new one uses more traditional version semantics (1.0.0, or the like).
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: ps and AIX field descriptors
On 2023-02-17 at 15:21, Greg Wooledge wrote: > On Fri, Feb 17, 2023 at 01:49:59PM -0500, The Wanderer wrote: > >> I can't speak to the new version, as I'm still running 3.3.17-7.1 on my >> machine - but I can at least note that the man page from that older >> version also explicitly says "a blank-separated or comma-separated list" >> in the description for the '-o' option, but the given command line (with >> a pipe for a separator) still works. (This may reflect only the same >> thing that you said, above.) >> >> It's entirely possible that this was an intentional change, to bring >> things in line with the documentation, and/or even one required in order >> to be in line with some appropriate specification. > > Hmm... fair point. POSIX says: > >The application shall ensure that the format specification is a list of >names presented as a single argument, or -separated. > > So the behavior of ps in bullseye is an extension of the POSIX requirement, > and apparently only applies to the "AIX format specifiers", which are yet > another extension. FWIW, at least in the 3.3.17-7.1 version I have, the man page claims that ps supports the POSIXLY_CORRECT environment variable. This type of more-strict POSIX compliance, even when it means being less capable, strikes me as the sort of thing that should probably be gated behind a check for that flag. > Nevertheless, this change definitely feels like a regression. Scripts > that are relying on the bullseye behavior, with full output formatting > capability, will no longer work in bookworm. > > I'm not using any such scripts, so I don't have anything to lose here, > but the OP might seriously want to get a bug report in, at least to > learn whether this is an intended regression, or an accidental one. Agreed, -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: ps and AIX field descriptors
On 2023-02-17 at 13:21, debian-u...@howorth.org.uk wrote: > Greg Wooledge wrote: > >> This sounds like a bug in procps that should be reported, if it >> hasn't already. > > It might be a bug if it disagreed with its documentation. But do the > docs say anything about this feature? What they do say is that you > should be able to use comma-separated field decriptions instead of > space-separated I think. Is that true for the new version? I can't speak to the new version, as I'm still running 3.3.17-7.1 on my machine - but I can at least note that the man page from that older version also explicitly says "a blank-separated or comma-separated list" in the description for the '-o' option, but the given command line (with a pipe for a separator) still works. (This may reflect only the same thing that you said, above.) It's entirely possible that this was an intentional change, to bring things in line with the documentation, and/or even one required in order to be in line with some appropriate specification. It might be interesting to dig up the actual commit message from the upstream development commit that made this change, and possibly also any here's-what's-changed-in-the-new-version documentation (whether in Debian or upstream), to see whether there's anything that sheds light on whether this was intentional and if so what the reason was. The answer might, at least, inform the approach to be taken in arguing for the restoration of this functionality in a potential future version. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Partitioning an SSD?
On 2023-02-16 at 08:10, Nicolas George wrote: > The Wanderer (12023-02-16): > >> filesystems et cetera aligned to physical blocks, because physical block >> size defines the minimum size that can be erased (and, therefore, >> overwritten) in any given operation, > > This is true. Note: erased, not written. My understanding is that in order to write data into a block which has already been written, the drive controller must erase the entire block and write it all again. Therefore, except for the narrow case of writing into a block which has never before been written, every write on a SSD *is* an erase+write operation. >> and therefore impacts both wear >> rates and write speeds in what is potentially a very serious way. > > This is not a logical consequence. > > You are assuming that if a block of flash memory contains B sectors, > then the block number b will contain the sectors from number B×b > included to number B×(b+1) excluded. > > 0 1 2 > ┌───┬───┬───┐ > ┌┬┬┬┬┬┬┬┬┬┬┬┐ >012346789 10 11 12 > > This is how it works for physical / logical sectors, but not for blocks > of flash memory. > > With flash memory, if you want to rewrite a sector, you can only write a > blank sector. > > So: you read the whole block, blank it, then re-write all the other > sectors and your updated sector? No, definitely not, that would be > terrible. That is exactly what I've always been told *does* happen, ever since first reading about how SSDs et cetera work, more than a decade ago. This is the first time I've seen a suggestion to the contrary. > What happens is, very schematically: the controller finds an unused > sector in a blank block (either one that has never been used or one that > has been recently erased), it writes the new data there, then updates > its remapping table to mark the old data obsolete and where the new data > is. That's an interesting design approach. Given that I've never seen it mentioned before, I imagine it must be comparatively recent as SSD controller designs go. I would not want to assume that every SSD does it; I would certainly not want to assume that there will always be such a block available, although in practice there *almost* always will be. I'm also not sure that I'd have chosen to take the trade-off of that added complexity for the presumed added performance and lack of need to keep track of block size handling. Additionally - I haven't thought it all the way through, but at a glance I'm wondering if this wouldn't also result in more total writes (thereby reducing the effective drive lifespan) than the way I've always been told it works; initial analysis isn't finding a way that it would, but I'm not sure I trust my initial analysis to have it right. > I do not know how the remapping table is kept; probably some kind of > journal with RAM caching. And of course, there are optimizations and > trade-offs: if a block contains only obsolete sectors except for a few > ones, it might make sense to move these non-obsolete sectors to a new > block to have the old one ready for erasure. I suspect constructors keep > what they do exactly as trade secrets. > > But the short of it is that it does not make sense to worry about > alignment, because even if you do, there is no guarantee that the first > sector of your partition will be the first sector of its block, and even > if it is it might not be tomorrow after it has been rewritten by the OS, > i.e. reallocated by the controller. So, if this is correct, we have both less understanding and less control of where and how data is stored on the drives than we think we do. Even if/though it's not common to *need* such, that hardly seems like it can possibly be considered a good thing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Partitioning an SSD?
On 2023-02-16 at 05:45, Nicolas George wrote: > DdB (12023-02-16): > >> Am 16.02.2023 um 09:31 schrieb Felix Miata: >> > None of the 25 or so SSDs/NVMEs I have have 4k sectors. e.g. >> >> Wow, they must be rather old, then. ;-) >> >> I know, i am not the only one ... >> https://serverfault.com/questions/1113068/how-to-find-page-size-of-my-ssd > > Of course you are not the only one. But the real answer was to be found > in another random stackoverflow forum: > > When you have 512 octets logical sectors and 4096 octets physical > sectors, you really have eight logical sectors in a physical one, it > matters to align the small ones inside the big ones. > > But with blocks of flash memory, there is not constant nor regular > mapping of sectors to blocks, so the information about the block size is > not useful outside of the disk controller. I'm already confused by the way terminology is being used in this conversation (and I wouldn't be surprised I wasn't the only one), but this is just "huh?" to me. My understanding is that with SSDs it's even *more* important to keep filesystems et cetera aligned to physical blocks, because physical block size defines the minimum size that can be erased (and, therefore, overwritten) in any given operation, and therefore impacts both wear rates and write speeds in what is potentially a very serious way. The way I interpret what I read you as having written, here, is that on the contrary block sizes can be completely disregarded because the disk controller will handle all of that alignment stuff internally. This being the very first time I can remember having encountered even the suggestion that there's no need to be concerned about erase-block sizes when dealing with SSDs et cetera, I hope it's understandable that I'd want to get things clarified. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
