Re: DEBIAN documentation: which 64 bit processors run current release?
On Thu, Aug 29, 2024 at 05:36:50AM -0500, Richard Owlett wrote: > > > > Richard Owlett wrote: > > > > > I'm looking for for where *Debian* documents which processors support > > > > > current Debian release. > > > > > > > > > > I have three machines whose processors are 64 bit capable. > > > > > Processors identified by running lscpu: > > > > > > > > > > Machine 1: > > > > > Architecture: i686 > > > > > Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz > > > > > > > > > > Machine 2: > > > > > Architecture: x86_64 > > > > > Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz > > > > > > > > > > Machine 3: > > > > > Architecture: i686 > > > > > Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz > > > > > > > > > > Will the OS linked to by https://www.debian.org/ run on all three? > > > > > [For historical reasons I currently run 32 bit on all.] > > > > > > [snip static ;] > > > > > > > > All of these CPUs should run Debian amd64. > > > > > > Weak point there is the word "should". Based on *your* background. > > > I was looking for documentation that *does not* assume the reader > > > has some unspecified expertise. > > less /proc/cpuinfo that will give you *all* the flags that your processor supports. "amd64 flag /proc/cpuinfo" into a search engine tells you that the flag you need reported is lm That doesn't assume prior expertise, particularly > > Did the documentation tell you to run lscpu and do something with the > > architecture field? > > No *GRIN* But is one of reasons I asked. > Over a half century of real real world experience suggested lscpu would be a > suitable reporting tool. > "What program shows CPU info in Linux" will give you https://www.techtarget.com/searchdatacenter/tip/How-to-check-your-CPU-in-a-Linux-system for example lscpu, /proc/cpuinfo and so on. > > > > FWIW, there isn't any reasonably general x86 OS that maintains a > > comprehensive list of every possible computer model it will run on. > > That was *NOT* the question. > > I ask "What doth DEBIAN require of my CPU?" > "Ask not what Debian requires of your CPU, ask what you require of Debian" and please engage positively with people who are trying to help. With every good wish, as ever, Andy Cater (amaca...@debian.org)
Re: DEBIAN documentation: which 64 bit processors run current release?
Richard Owlett wrote: > My formal programming background is limited to an introductory course > using CORC/CUPL (Dartmouth's BASIC being years in future). [snip] That doesn't seem to be quite right. CORC preceded Dartmouth BASIC by a couple of years, whilst CUPL followed it by two years, if I am to believe wikipedia. > On 08/28/2024 09:07 PM, Michael Stone wrote: > > It seems to me that you're doing your own thing in > > your own way and expecting us to accomodate that, which seems at > > least somewhat unreasonable. For background: the lscpu architecture > > field doesn't tell you what kind of cpu you're running. Instead, it > > tells you the architecture of the system on which lscpu is running, > > and more specifically, what architecture the *kernel* is built > > for. > > DEBIAN documentation appears to disagree with you.The manpage[1] > states: > > lscpu - display information about the CPU architecture You are once again personalising matters when there's no need, as well as getting facts wrong. This is bad; please try to improve. Debian is sometimes spelled with mixed case as I have done, and sometimes all in lower case. It is not usually spelled all in upper case and doing so in email makes it seem that you are shouting the word for emphasis. Maybe you are, but you are wrong to do so. Firstly, manpages are not "Debian documentation". That is, they are for the most part generated by the authors of individual packages and are then incorporated in Debian. Sometimes a Debian member will write a manpage if there is none for a particular package. Secondly, when reading a manpage it is wise not to rely too much on the one-line description. If you read the rest of the page it tells you where the information comes from and you could imply more from that. > > FWIW, there isn't any reasonably general x86 OS that maintains a > > comprehensive list of every possible computer model it will run > > on. > > That was *NOT* the question. > > I ask "What doth DEBIAN require of my CPU?" Again, you seem to be railing against people who are trying to help you. The most important thing to do is to try to improve how you express yourself, and how you interpret what other people say. I hope you can. > [1] https://manpages.debian.org/bookworm/util-linux/lscpu.1.en.html
Re: DEBIAN documentation: which 64 bit processors run current release?
On Thu, Aug 29, 2024 at 05:36:50AM -0500, Richard Owlett wrote:
My formal programming background is limited to an introductory course
using CORC/CUPL (Dartmouth's BASIC being years in future). My last
production code used 8080 assembler - my employer hadn't yet switched
completely to 8085. I've owned a variety of machines - early a PET and
a Kim. Still have a Kaypro 10 in a back room - haven't booted in
decades.
Thank you for the history lesson? I don't see how it impacts how you
should interact with people who tried to help you on a public forum.
On 08/28/2024 09:07 PM, Michael Stone wrote:
On Tue, Aug 27, 2024 at 09:10:21AM -0500, Richard Owlett wrote:
Did the documentation tell you to run lscpu and do something with
the architecture field?
No *GRIN* But is one of reasons I asked.
Over a half century of real real world experience suggested lscpu
would be a suitable reporting tool.
Adding a GRIN doesn't improve things at this point.
When people tried to assist you, you complained:
Not Debian documentation.
Though x86_64 is mentioned in footnotes there is none to indicate that i686
can run Debian 64 bit software (only mention is about 32 bit)
but *you* are the one who brought i686 into the discussion, based on
reading the wrong line in lscpu and going off on a tangent. It's not
their fault that you can't find a reference in the documentation to
information not relevant to the question.
As a matter of fact lscpu can help answer the question, but it's the
second line ("CPU op-mode(s)") that indicates whether the CPU supports
64-bit instructions even if running on a 32 bit kernel, not the
"Architecture" line. *But*, I'm not sure the op-mode line is fully
determinative in the presence of machines which don't support booting
into 64 bit mode even though the CPU supports 64 bit instructions. (I
simply can't recall if the CPU on such a system would mask out support
for 64-bit instructions; I suspect not, but it's been a long time since
I encountered one of those and have no way to confirm the behavior.)
That's why I said you need to either go on a fruitless search for good
system documentation or simply boot the thing to answer the question.
I guess one could argue that it isn't clear that "64-bit op-modes"
aren't referenced specifically in the documentation, but the
countargument would be that the documentation doesn't try to answer the
question based on lscpu output in the first place, probably because it
assumes that anyone who's gotten to the point of running lscpu could very
well run the installer itself.
It seems to me that you're doing your own thing in your own way and
expecting us to accomodate that, which seems at least somewhat
unreasonable. For background: the lscpu architecture field doesn't
tell you what kind of cpu you're running. Instead, it tells you the
architecture of the system on which lscpu is running, and more
specifically, what architecture the *kernel* is built for.
DEBIAN documentation appears to disagree with you.The manpage[1] states:
lscpu - display information about the CPU architecture
That in no way conflicts with what I wrote. The specific "Architecture"
field is information about the CPU architecture, but comes from the
kernel running on the CPU and does not necessarily reflect the full
capabilities of the CPU itself (without regard to limitations of the
booted kernel). Other fields do come directly from the CPU. All of the
information together is useful to determine what programs can execute on
the system.
FWIW, there isn't any reasonably general x86 OS that maintains a
comprehensive list of every possible computer model it will run on.
That was *NOT* the question.
I ask "What doth DEBIAN require of my CPU?"
Check the subject line--are you sure that's what you actually asked?
Your original message said: "I'm looking for for where *Debian*
documents which processors support current Debian release." In any
event, the question has been answered multiple times: you need a
processor that supports the AMD64 or Intel 64 instruction sets. You've
referenced that documentation yourself. You've been told that you need
to figure out if your system supports those instructions because debian
doesn't know, and that the easiest way to do so is to simply boot the
installer.
For most people it's sufficient to know that basically any mainstream
computer for the past 10 years supports amd64. Or, they'd just boot it
and find out. But you're in the singular position of demanding a more
complex and technical answer, while simultaneously demanding that the
answer be aimed at a reader with no technical expertise. Sorry, nobody
has written that because the audience of people who have no technical
knowledge but
Re: DEBIAN documentation: which 64 bit processors run current release?
My formal programming background is limited to an introductory course using CORC/CUPL (Dartmouth's BASIC being years in future). My last production code used 8080 assembler - my employer hadn't yet switched completely to 8085. I've owned a variety of machines - early a PET and a Kim. Still have a Kaypro 10 in a back room - haven't booted in decades. On 08/28/2024 09:07 PM, Michael Stone wrote: On Tue, Aug 27, 2024 at 09:10:21AM -0500, Richard Owlett wrote: On 08/27/2024 08:14 AM, Dan Ritter wrote: Richard Owlett wrote: I'm looking for for where *Debian* documents which processors support current Debian release. I have three machines whose processors are 64 bit capable. Processors identified by running lscpu: Machine 1: Architecture: i686 Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz Machine 2: Architecture: x86_64 Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz Machine 3: Architecture: i686 Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz Will the OS linked to by https://www.debian.org/ run on all three? [For historical reasons I currently run 32 bit on all.] [snip static ;] All of these CPUs should run Debian amd64. Weak point there is the word "should". Based on *your* background. I was looking for documentation that *does not* assume the reader has some unspecified expertise. Did the documentation tell you to run lscpu and do something with the architecture field? No *GRIN* But is one of reasons I asked. Over a half century of real real world experience suggested lscpu would be a suitable reporting tool. It seems to me that you're doing your own thing in your own way and expecting us to accomodate that, which seems at least somewhat unreasonable. For background: the lscpu architecture field doesn't tell you what kind of cpu you're running. Instead, it tells you the architecture of the system on which lscpu is running, and more specifically, what architecture the *kernel* is built for. DEBIAN documentation appears to disagree with you.The manpage[1] states: lscpu - display information about the CPU architecture Only suggestion that it may not be physical reality is when it states: In virtualized environments, the CPU architecture information displayed reflects the configuration of the guest operating system which is typically different from the physical (host) system. FWIW, there isn't any reasonably general x86 OS that maintains a comprehensive list of every possible computer model it will run on. That was *NOT* the question. I ask "What doth DEBIAN require of my CPU?" [1] https://manpages.debian.org/bookworm/util-linux/lscpu.1.en.html
Re: DEBIAN documentation: which 64 bit processors run current release?
On Tue, Aug 27, 2024 at 09:10:21AM -0500, Richard Owlett wrote: On 08/27/2024 08:14 AM, Dan Ritter wrote: Richard Owlett wrote: I'm looking for for where *Debian* documents which processors support current Debian release. I have three machines whose processors are 64 bit capable. Processors identified by running lscpu: Machine 1: Architecture: i686 Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz Machine 2: Architecture: x86_64 Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz Machine 3: Architecture: i686 Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz Will the OS linked to by https://www.debian.org/ run on all three? [For historical reasons I currently run 32 bit on all.] https://www.debian.org/releases/stable/amd64/ch02s01.en.html That was the USELESS page prompting the question! and [snip more rudeness] OFF-TOPIC: I explicitly asked for *DEBIAN DOCUMENTATION*. and https://ark.intel.com/content/www/us/en/ark/products/30774/intel-celeron-processor-540-1m-cache-1-86-ghz-533-mhz-fsb.html says that the M540 also has that, so will also run amd64. OFF-TOPIC: I explicitly asked for *DEBIAN DOCUMENTATION*. All of these CPUs should run Debian amd64. Weak point there is the word "should". Based on *your* background. I was looking for documentation that *does not* assume the reader has some unspecified expertise. Did the documentation tell you to run lscpu and do something with the architecture field? It seems to me that you're doing your own thing in your own way and expecting us to accomodate that, which seems at least somewhat unreasonable. For background: the lscpu architecture field doesn't tell you what kind of cpu you're running. Instead, it tells you the architecture of the system on which lscpu is running, and more specifically, what architecture the *kernel* is built for. If you run lscpu on a bookworm i386 system with the default kernel, it will say i686. If you reboot the system with an amd64 kernel, it will say x86_64, even though it's the same i386 install! You can see why giving us this line is completely USELESS? (So how would an amd64 kernel get on an i386 install? Two ways: in older versions, there were multiple kernel options like i486, i686, and amd64, and the user could select any of them. The benefit of using an amd64 kernel on an i386 install was that you could utilize more memory efficiently. With a current release if you want to do the same thing you can set up a multiarch system or just install the amd64 deb and force the architecture.) As others have suggested, the bottom line is that debian doesn't know whether *your machine* can run debian amd64. In general most computers from the past 10+ years can, even many from the past 20+ years. The cpu manufacturer documentation will give you some information (e.g., intel ark says for the E5300: "Intel® 64 Yes"). But it's possible that a computer might not support 64 bit mode even if the cpu does (not common now, but was a thing once upon a time) so you'd need to also check the computer manufacturer's documentation. The practical answer, because documentation for old computers is hard to find and mostly was terrible when it was written, is to simply run the amd64 netinst or live image: if 64 bit mode isn't supported, it won't run. FWIW, there isn't any reasonably general x86 OS that maintains a comprehensive list of every possible computer model it will run on. There may be a list of machines it was tested on, but that will be a subset of all possible machines. The odds that your specific old machine is on any such list for a current OS is fairly small, whether from debian or anyone else.
Re: Which tool for upgrade in commandline?
See also Debian Reference Chapter 2. Debian package management 2.2.1. apt vs. apt-get / apt-cache vs. aptitude https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_literal_apt_literal_vs_literal_apt_get_literal_literal_apt_cache_literal_vs_literal_aptitude_literal Regards, Jörg.
Re: Which tool for upgrade in commandline?
On Tue 27 Aug 2024 at 20:32:04 (+0100), Joe wrote: > On Tue, 27 Aug 2024 21:03:02 +0200 Hans wrote: > > First, we have the oldest, whcih is apt-get. > > apt-get update, apt-get upgrade or apt-get full-upgrade does a good > > job. > > So, my question is: Which one is recommended, when updating and > > upgrading is used in a script, so that it causes as little as > > possible pain? > > > > It means: When the script is not eecuted daily, but let us say, every > > two weeks, and we have lots of packages. > > > > At the moment I am using aptitude, this works great in short periods, > > but after al longer time, it crashes, because some dependencies could > > not resolve. > > > > Independent of my personal use: Which one is recommended? For scripts, apt-get has the advantage that it doesn't get changed from release to release, but always behaves the same way. > I believe apt is currently recommended. Having said that, sometimes the > upgrade notes for a new Stable recommend using a particular tool, and > obviously you would go with that advice. I seem to recall that apt will > not just use one of the earlier upgrade tools, but will do a bit of > tidying up afterwards. With the earlier tools, the package cache has to > be manually cleared periodically. For upgrading one release to another, apt is currently recommended, but I think it's assumed that you do this by typing the commands rather than just running a script, so you can check for success at each step. > My experience of apt-get and aptitude is that aptitude has a better > resolver and will often clear a medium-sized pile of packages when > apt-get won't. However, it achieves this improved performance at the > expense of speed and simplicity. If you run Unstable, especially, and > leave upgrading too long, aptitude can be overwhelmed by several hundred > packages to organise, and will apparently just hang. Aptitude should be > fine on Stable, which should never have more than about a dozen > packages upgradable, unless you leave it for many months. I'd still use > apt. With anything up to stable, I've never had a problem using apt-get. For example, last week I upgraded a buster (oldoldstable) system that was last upgraded in early March. A mere 171 packages with one command. But sure, for testing and beyond, the quirks in the resolvers will make a difference as there are more packages to upgrade and not even a guarantee that the distribution is complete. Cheers, David.
Re: Which tool for upgrade in commandline?
On Tue, Aug 27, 2024 at 5:36 PM Hans wrote: > > Dear list, > > over the many years we got different tools for upgrading debian in the > commandline. These tools behave differently and also we get different results, > when eecuting. > > First, we have the oldest, whcih is apt-get. > apt-get update, apt-get upgrade or apt-get full-upgrade does a good job. > > However, we also have aptitude, but > aptitude update, aptitude upgrade and aptitude full-upgrade are doing also a > good job, but not the same as apt-get does. Also it looks, aptitude update > loads its own list and is not using the list from apt-get (otherwise it could > not explain, why aptitude and apt-get every time reloads the new list, when > one of the other was eecuted before). Also the dependencies in both tools are > handled different. > > And at last, we have apt, which (as far as I now), soemtimes is calling apt- > get, and sometimes is calling aptitude. > > This is somehow rather irritating! > > So, my question is: Which one is recommended, when updating and upgrading is > used in a script, so that it causes as little as possible pain? > > It means: When the script is not eecuted daily, but let us say, every two > weeks, and we have lots of packages. > > At the moment I am using aptitude, this works great in short periods, but > after al longer time, it crashes, because some dependencies could not resolve. > > Independent of my personal use: Which one is recommended? <https://www.debian.org/doc/manuals/debian-faq/uptodate.en.html>. Jeff
Re: Which tool for upgrade in commandline?
Hi, On Wed, Aug 28, 2024 at 04:25:20AM +0800, Bret Busby wrote: > On 28/8/24 03:03, Hans wrote: > > So, my question is: Which one is recommended, when updating and upgrading is > > used in a script, so that it causes as little as possible pain? […] > apt update && apt full-upgrade -y && apt autoremove -y && apt autoclean "apt" will say when it is used in a script that its user interface is not yet stable (i.e. its output could change at any time) so it should not be used in scripts. Other replies have already covered the correct answer for non-interactive use. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Which tool for upgrade in commandline?
On 28/8/24 03:03, Hans wrote: Dear list, over the many years we got different tools for upgrading debian in the commandline. These tools behave differently and also we get different results, when eecuting. First, we have the oldest, whcih is apt-get. apt-get update, apt-get upgrade or apt-get full-upgrade does a good job. However, we also have aptitude, but aptitude update, aptitude upgrade and aptitude full-upgrade are doing also a good job, but not the same as apt-get does. Also it looks, aptitude update loads its own list and is not using the list from apt-get (otherwise it could not explain, why aptitude and apt-get every time reloads the new list, when one of the other was eecuted before). Also the dependencies in both tools are handled different. And at last, we have apt, which (as far as I now), soemtimes is calling apt- get, and sometimes is calling aptitude. This is somehow rather irritating! So, my question is: Which one is recommended, when updating and upgrading is used in a script, so that it causes as little as possible pain? It means: When the script is not eecuted daily, but let us say, every two weeks, and we have lots of packages. At the moment I am using aptitude, this works great in short periods, but after al longer time, it crashes, because some dependencies could not resolve. Independent of my personal use: Which one is recommended? Thanks for reading. Short answer will be ok. Best Hans apt update && apt full-upgrade -y && apt autoremove -y && apt autoclean Simple. .. Bret Busby Armadale West Australia (UTC+0800) ..
Re: Which tool for upgrade in commandline?
On 27 Aug 2024 19:28 +, from amaca...@einval.com (Andrew M.A. Cater): > apt-get [...] is recommended for upgrading between Debian major releases. Is it, though? https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#updating-lists https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrading-full `apt` is named as the primary tool and the example command lines use it; `apt-get` is mentioned in a couple of corresponding notes, particularly with regards to its benefits when used from scripts. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Which tool for upgrade in commandline?
On Tue, 27 Aug 2024 21:03:02 +0200 Hans wrote: > Dear list, > > over the many years we got different tools for upgrading debian in > the commandline. These tools behave differently and also we get > different results, when eecuting. > > First, we have the oldest, whcih is apt-get. > apt-get update, apt-get upgrade or apt-get full-upgrade does a good > job. > > However, we also have aptitude, but > aptitude update, aptitude upgrade and aptitude full-upgrade are doing > also a good job, but not the same as apt-get does. Also it looks, > aptitude update loads its own list and is not using the list from > apt-get (otherwise it could not explain, why aptitude and apt-get > every time reloads the new list, when one of the other was eecuted > before). Also the dependencies in both tools are handled different. I believe they use different cache structures, and if tool A has been used since tool B was last used, next time tool B is used it will not know what has been upgraded while it has 'been away', and will refresh its own cache. > > And at last, we have apt, which (as far as I now), soemtimes is > calling apt- get, and sometimes is calling aptitude. > > This is somehow rather irritating! > > So, my question is: Which one is recommended, when updating and > upgrading is used in a script, so that it causes as little as > possible pain? > > It means: When the script is not eecuted daily, but let us say, every > two weeks, and we have lots of packages. > > At the moment I am using aptitude, this works great in short periods, > but after al longer time, it crashes, because some dependencies could > not resolve. > > Independent of my personal use: Which one is recommended? > I believe apt is currently recommended. Having said that, sometimes the upgrade notes for a new Stable recommend using a particular tool, and obviously you would go with that advice. I seem to recall that apt will not just use one of the earlier upgrade tools, but will do a bit of tidying up afterwards. With the earlier tools, the package cache has to be manually cleared periodically. My experience of apt-get and aptitude is that aptitude has a better resolver and will often clear a medium-sized pile of packages when apt-get won't. However, it achieves this improved performance at the expense of speed and simplicity. If you run Unstable, especially, and leave upgrading too long, aptitude can be overwhelmed by several hundred packages to organise, and will apparently just hang. Aptitude should be fine on Stable, which should never have more than about a dozen packages upgradable, unless you leave it for many months. I'd still use apt. -- Joe
Re: Which tool for upgrade in commandline?
On 27 Aug 2024 21:03 +0200, from hans.ullr...@loop.de (Hans): > So, my question is: Which one is recommended, when updating and upgrading is > used in a script, so that it causes as little as possible pain? apt-get and friends, including the dpkg set of tools if necessary. I believe apt even prints a message to that effect when started. See also the introductory paragraph of the apt(8) man page. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Which tool for upgrade in commandline?
On Tue, Aug 27, 2024 at 09:03:02PM +0200, Hans wrote: > Dear list, > > This is somehow rather irritating! > > So, my question is: Which one is recommended, when updating and upgrading is > used in a script, so that it causes as little as possible pain? > apt-get is potentially the most basic. Aptitude resolves dependencies differently and sometimes more effectively. Apt as such I don't use (even though I named the whole idea :) ) apt-get normally "just works" which is why it is recommended for upgrading between Debian major releases. > It means: When the script is not eecuted daily, but let us say, every two > weeks, and we have lots of packages. > There is something about the number of packages installed at once and interdependencies - maybe run whichever more often. Installing 20 packages at a time may be easier than installing 80 packages at once, for example. > At the moment I am using aptitude, this works great in short periods, but > after al longer time, it crashes, because some dependencies could not > resolve. > > Independent of my personal use: Which one is recommended? > Whichever one works for you ... there is no definitive answer. > Thanks for reading. Short answer will be ok. ok - the short answer you already predicted :) > > Best > > Hans > All the very best, as ever, Andy (amaca...@debian.org) > > >
Re: Which tool for upgrade in commandline?
On Tuesday, 27 August 2024 15:03:02 -04 Hans wrote: > Dear list, > > over the many years we got different tools for upgrading debian in the > commandline. These tools behave differently and also we get different > results, when eecuting. > > First, we have the oldest, whcih is apt-get. > apt-get update, apt-get upgrade or apt-get full-upgrade does a good > job. > > However, we also have aptitude, but > aptitude update, aptitude upgrade and aptitude full-upgrade are doing > also a good job, but not the same as apt-get does. Also it looks, > aptitude update loads its own list and is not using the list from > apt-get (otherwise it could not explain, why aptitude and apt-get > every time reloads the new list, when one of the other was eecuted > before). Also the dependencies in both tools are handled different. > > And at last, we have apt, which (as far as I now), soemtimes is > calling apt- get, and sometimes is calling aptitude. > > This is somehow rather irritating! Do you really mean irritating or just confusing? "irritating" equals the German "verärgert"; while "confusing" is what Germans just find "irritierend". :-) > > So, my question is: Which one is recommended, when updating and > upgrading is used in a script, so that it causes as little as > possible pain? > > It means: When the script is not eecuted daily, but let us say, every > two weeks, and we have lots of packages. > > At the moment I am using aptitude, this works great in short periods, > but after al longer time, it crashes, because some dependencies could > not resolve. > > Independent of my personal use: Which one is recommended? > > Thanks for reading. Short answer will be ok. > > Best > > Hans I'd like to know too. I usually use apt. Sometimes aptitude when I'm looking for something - me being lazy. But I find aptitude to be inconvenient when trying to resolve dependency problems. Packages which aptitude will not purge can easily be deinstalled, including all configuration files, by invoking apt purge for example. All the best -- Eike Lantzsch KY4PZ / ZP5CGE
Which tool for upgrade in commandline?
Dear list, over the many years we got different tools for upgrading debian in the commandline. These tools behave differently and also we get different results, when eecuting. First, we have the oldest, whcih is apt-get. apt-get update, apt-get upgrade or apt-get full-upgrade does a good job. However, we also have aptitude, but aptitude update, aptitude upgrade and aptitude full-upgrade are doing also a good job, but not the same as apt-get does. Also it looks, aptitude update loads its own list and is not using the list from apt-get (otherwise it could not explain, why aptitude and apt-get every time reloads the new list, when one of the other was eecuted before). Also the dependencies in both tools are handled different. And at last, we have apt, which (as far as I now), soemtimes is calling apt- get, and sometimes is calling aptitude. This is somehow rather irritating! So, my question is: Which one is recommended, when updating and upgrading is used in a script, so that it causes as little as possible pain? It means: When the script is not eecuted daily, but let us say, every two weeks, and we have lots of packages. At the moment I am using aptitude, this works great in short periods, but after al longer time, it crashes, because some dependencies could not resolve. Independent of my personal use: Which one is recommended? Thanks for reading. Short answer will be ok. Best Hans
Re: DEBIAN documentation: which 64 bit processors run current release?
вт, 27 авг. 2024 г. в 21:26, Richard Owlett : > > I'm looking for for where *Debian* documents which processors support > current Debian release. > https://www.debian.org/releases/stable/amd64/ch02s01.en.html """ 2.1.2. CPU Support Both AMD64 and Intel 64 processors are supported. """ Debian is not an enterprise distribution, so does not have HCL for tested hardware and you will not be subject to any penalties when you install it on hardware not in HCL. > I have three machines whose processors are 64 bit capable. > Processors identified by running lscpu: > > Machine 1: > Architecture: i686 > Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz > > Machine 2: > Architecture: x86_64 > Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz > > Machine 3: > Architecture: i686 > Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz > > Will the OS linked to by https://www.debian.org/ run on all three? Yes. All three. -- Stanislav
Re: DEBIAN documentation: which 64 bit processors run current release?
Richard Owlett wrote: > On 08/27/2024 08:36 AM, David wrote: > > On Tue, 27 Aug 2024 at 13:06, Richard Owlett > > wrote: > >> I'm looking for for where *Debian* documents which processors > >> support current Debian release. > >> > >> I have three machines whose processors are 64 bit capable. > > > > To add to Dan's reply: > > https://www.debian.org/ports/ > > No mention of i686 nor x86_64. > > > https://www.debian.org/ports/amd64/ > > No mention of i686 nor x86_64. I agree that the Debian documentation doesn't seem to answer your question, which I paraphrase as "Does XXX model of CPU run Debian?". However I'd argue that your response to the various suggestions offered has been over-critical. I'd also say that I think that given the large number of possible CPU types and the fact AIUI that Debian doesn't care at all, simply accepting whatever the kernel folks do, plus the limited resources of the Debian community, it doesn't surprise me that their documentation doesn't answer the question. > > https://en.wikipedia.org/wiki/X86-64 > > Not Debian documentation. > Though x86_64 is mentioned in footnotes there is none to indicate > that i686 can run Debian 64 bit software (only mention is about 32 > bit) Given my explanation above, I think it is reasonable to look elsewhere than Debian documentation for an answer to your question, and this wikipedia page appears to provide an answer to it. Your processors are specifically mentioned AFAICT.
Re: DEBIAN documentation: which 64 bit processors run current release?
Richard Owlett wrote: > On 08/27/2024 08:14 AM, Dan Ritter wrote: > > Richard Owlett wrote: > > > I'm looking for for where *Debian* documents which processors support > > > current Debian release. ... > > https://www.debian.org/releases/stable/amd64/ch02s01.en.html > > That was the USELESS page prompting the question! No, it was the useful page that you didn't understand. > > https://www.debian.org/releases/stable/i386/ch02s01.en.html > > That page is 32 bit oriented. I wish to run *64 bit*. There I was thinking that we would have a friendly interaction. Instead you yell at me, ignore what I wrote, and insist that not only does the world have to cater to you, but it also has to spoon-feed you information in the exact texture that you prefer. > > https://ark.intel.com/content/www/us/en/ark/products/35300/intel-pentium-processor-e5300-2m-cache-2-60-ghz-800-mhz-fsb.html > > says that the e5300 has the 64 bit instruction set, so it will > > also run the amd64 release. > > OFF-TOPIC: I explicitly asked for *DEBIAN DOCUMENTATION*. I gave you the Debian docs. It tells you what you need to look for. It is not Debian's responsbility, nor would it be a good use of a volunteer's time, to keep track of every CPU ever made. Then I gave you the precise reference documentation. It *IS* Intel's responsibility to keep track of their CPU list, and they do so quite well. > Weak point there is the word "should". Based on *your* background. These CPUs *can* run the Debian AMD64 port. Will your specific machines? Probably, but there are always manufacturers who decide to do something bizarre in the name of profit. Nobody can give you a definitive answer without trying it out on your specific machines. And that's what you should do. > I was looking for documentation that *does not* assume the reader has some > unspecified expertise. You were looking to not just be spoonfed the answer, but to not have to learn anything. Tough noogies. Plonk.
Re: DEBIAN documentation: which 64 bit processors run current release?
On Tue, Aug 27, 2024 at 11:16 AM Richard Owlett wrote: > > I'm looking for for where *Debian* documents which processors support > current Debian release. <https://www.debian.org/releases/stable/i386/ch02s01.en.html> > I have three machines whose processors are 64 bit capable. > Processors identified by running lscpu: > > Machine 1: > Architecture: i686 > Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz > > Machine 2: > Architecture: x86_64 > Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz > > Machine 3: > Architecture: i686 > Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz > > Will the OS linked to by https://www.debian.org/ run on all three? > [For historical reasons I currently run 32 bit on all.] Jeff
Re: DEBIAN documentation: which 64 bit processors run current release?
On Aug 27, 2024, Richard Owlett wrote: > I'm looking for for where *Debian* documents which processors support > current Debian release. > > I have three machines whose processors are 64 bit capable. > Processors identified by running lscpu: > > Machine 1: > Architecture: i686 > Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz > > Machine 2: > Architecture: x86_64 > Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz > > Machine 3: > Architecture: i686 > Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz > > Will the OS linked to by https://www.debian.org/ run on all three? > [For historical reasons I currently run 32 bit on all.] As I recall "i686" is a 32-bit "architecture" (i.e. the "80686" aka the P4 -- something something trademarks, etc. after the '486). That being said, the i5-m540 is certainly 64-bit hardware according to Intel's spec sheets. Likewise the Pentium-E5300 ([1] and [2], respectively). Not really sure why lscpu would tell you they're 32-bit then, outside of "error" caused by running a 32-bit OS. As long as they show the 'lm' flag in lscpu, you'll quite likely be fine. There aren't really any artificial restrictions or requirements, such as the TPM module (or whichever generation of the SSE instruction set). For comparison, I have buster or bullseye running on some ancient AMD PhenomII (exact processor forgotten at the moment, I want to say '09 vintage). Your biggest concern would likely be how much RAM the systems in question have * Anything less than 2GB probably isn't worth it * >2G <=4G will "work", though I'd hazard it will always feel sluggish * >4G will likely work fine under "light" loads (i.e. you'll probably kill it with more than a handful of browser tabs open) For reference, that old PhenomII box I mentioned has 6G of RAM, and its main problem is "heat" moreso than lack of RAM -- as I recall, the darn thing likes to idle at 55C or so (I really "should" replace the thermal compound, but also why bother, it's just for plugging an arduino into and playing about on the workbench so WHEN I screw up, I don't ruin my nice machine :)). [1] https://ark.intel.com/content/www/us/en/ark/products/43544/intel-core-i5-540m-processor-3m-cache-2-53-ghz.html [2] https://ark.intel.com/content/www/us/en/ark/products/35300/intel-pentium-processor-e5300-2m-cache-2-60-ghz-800-mhz-fsb.html -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 signature.asc Description: PGP signature
Re: DEBIAN documentation: which 64 bit processors run current release?
On 08/27/2024 08:36 AM, David wrote: On Tue, 27 Aug 2024 at 13:06, Richard Owlett wrote: I'm looking for for where *Debian* documents which processors support current Debian release. I have three machines whose processors are 64 bit capable. To add to Dan's reply: https://www.debian.org/ports/ No mention of i686 nor x86_64. https://www.debian.org/ports/amd64/ No mention of i686 nor x86_64. https://en.wikipedia.org/wiki/X86-64 Not Debian documentation. Though x86_64 is mentioned in footnotes there is none to indicate that i686 can run Debian 64 bit software (only mention is about 32 bit) https://en.wikipedia.org/wiki/IA-32 Not Debian documentation and OFF-TOPIC as it is strictly about 32 bit.
Re: DEBIAN documentation: which 64 bit processors run current release?
On 08/27/2024 08:14 AM, Dan Ritter wrote: Richard Owlett wrote: I'm looking for for where *Debian* documents which processors support current Debian release. I have three machines whose processors are 64 bit capable. Processors identified by running lscpu: Machine 1: Architecture: i686 Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz Machine 2: Architecture: x86_64 Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz Machine 3: Architecture: i686 Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz Will the OS linked to by https://www.debian.org/ run on all three? [For historical reasons I currently run 32 bit on all.] https://www.debian.org/releases/stable/amd64/ch02s01.en.html That was the USELESS page prompting the question! and https://www.debian.org/releases/stable/i386/ch02s01.en.html That page is 32 bit oriented. I wish to run *64 bit*. will tell you that the difference is whether the CPU has the amd64 (also called x86_64) instruction set. So machine 2 with the t7300 will definitely run the amd64 release. Next you need to look at the manufacturer's documentation. In this case, Intel: https://ark.intel.com/content/www/us/en/ark/products/35300/intel-pentium-processor-e5300-2m-cache-2-60-ghz-800-mhz-fsb.html says that the e5300 has the 64 bit instruction set, so it will also run the amd64 release. OFF-TOPIC: I explicitly asked for *DEBIAN DOCUMENTATION*. and https://ark.intel.com/content/www/us/en/ark/products/30774/intel-celeron-processor-540-1m-cache-1-86-ghz-533-mhz-fsb.html says that the M540 also has that, so will also run amd64. OFF-TOPIC: I explicitly asked for *DEBIAN DOCUMENTATION*. All of these CPUs should run Debian amd64. Weak point there is the word "should". Based on *your* background. I was looking for documentation that *does not* assume the reader has some unspecified expertise. -dsr-
Re: DEBIAN documentation: which 64 bit processors run current release?
> Will the OS linked to by https://www.debian.org/ run on all three? Yes, on all three, both using the i386 (which is being phased out) or the amd64 ports. Stefan
Re: DEBIAN documentation: which 64 bit processors run current release?
On Tue, 27 Aug 2024 at 13:06, Richard Owlett wrote: > I'm looking for for where *Debian* documents which processors support > current Debian release. > > I have three machines whose processors are 64 bit capable. To add to Dan's reply: https://www.debian.org/ports/ https://www.debian.org/ports/amd64/ https://en.wikipedia.org/wiki/X86-64 https://en.wikipedia.org/wiki/IA-32
Re: DEBIAN documentation: which 64 bit processors run current release?
Richard Owlett wrote: > I'm looking for for where *Debian* documents which processors support > current Debian release. > > I have three machines whose processors are 64 bit capable. > Processors identified by running lscpu: > > Machine 1: > Architecture: i686 > Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz > > Machine 2: > Architecture: x86_64 > Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz > > Machine 3: > Architecture: i686 > Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz > > Will the OS linked to by https://www.debian.org/ run on all three? > [For historical reasons I currently run 32 bit on all.] https://www.debian.org/releases/stable/amd64/ch02s01.en.html and https://www.debian.org/releases/stable/i386/ch02s01.en.html will tell you that the difference is whether the CPU has the amd64 (also called x86_64) instruction set. So machine 2 with the t7300 will definitely run the amd64 release. Next you need to look at the manufacturer's documentation. In this case, Intel: https://ark.intel.com/content/www/us/en/ark/products/35300/intel-pentium-processor-e5300-2m-cache-2-60-ghz-800-mhz-fsb.html says that the e5300 has the 64 bit instruction set, so it will also run the amd64 release. and https://ark.intel.com/content/www/us/en/ark/products/30774/intel-celeron-processor-540-1m-cache-1-86-ghz-533-mhz-fsb.html says that the M540 also has that, so will also run amd64. All of these CPUs should run Debian amd64. -dsr-
DEBIAN documentation: which 64 bit processors run current release?
I'm looking for for where *Debian* documents which processors support current Debian release. I have three machines whose processors are 64 bit capable. Processors identified by running lscpu: Machine 1: Architecture: i686 Model name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz Machine 2: Architecture: x86_64 Model name: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz Machine 3: Architecture: i686 Model name: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz Will the OS linked to by https://www.debian.org/ run on all three? [For historical reasons I currently run 32 bit on all.] TIA
Re: What tool(s) reports OS buss width, which processor present?
Hello, On Thu, Aug 22, 2024 at 08:38:20AM -0400, Stefan Monnier wrote: > > cross-graded to amd64 only as far as running the amd64 kernel while > > leaving all of the user land and the primary dpkg architecture as > > i386. This is a supported configuration. > > It's not just "supported": it's basically the recommended setup for an > i386 install, since the support for the i386 kernels is being EOL'd. Others may have noticed me already pointing this out at length in other threads. 😀 If you start with a system that was installed as i386 it's easy to just install an amd64 kernel. Some try to fully cross-grade userland to amd64, e.g.: https://wiki.debian.org/CrossGradingo Or by using this script: https://salsa.debian.org/crossgrading-team/debian-crossgrading/-/blob/master/INSTRUCTIONS.md However, both of those involve some very hairy steps. It's never been fully automatic for me and has involved some outcomes that were tricky to recover from. I wouldn't recommend that a non-expert tries it. It took longer than just reinstalling. I have had customers try to do this and end up taking a wrong step, resulting in a very broken system. Repairing it for them isn't something they pay me for so I've advised reinstall at that point also. So on most of these legacy systems I stopped with just the kernel, since that's the majority of the benefit anyway. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: What tool(s) reports OS buss width, which processor present?
> cross-graded to amd64 only as far as running the amd64 kernel while > leaving all of the user land and the primary dpkg architecture as > i386. This is a supported configuration. It's not just "supported": it's basically the recommended setup for an i386 install, since the support for the i386 kernels is being EOL'd. Stefan
Re: What tool(s) reports OS buss width, which processor present?
On Wed, Aug 21, 2024 at 10:41 AM Richard Owlett wrote: > > I know I've asked this before, but couldn't thread. > /etc/debian_version reports release active, but I need to know 32 or 64 bit. Which bus width do you want to know? Address, data, pci, agp, something else? Jeff
Re: DUH - was [Re: What tool(s) reports OS buss width, which processor present?]
On 21/8/24 19:43, Richard Owlett wrote: On 08/21/2024 06:34 AM, Richard Owlett wrote: I know I've asked this before, but couldn't thread. /etc/debian_version reports release active, but I need to know 32 or 64 bit. TIA Just finished coffee - inspiration I use MATE just checked Application->System Tools->Mate System Monitor I tells all ;) It's not the answer I received before but is MATE specific. The answer I had been given depended only on Debian itself. Sorry for the noise. Delpending on how much information you want at a time, you might like to download, install, and run neofetch. .. Bret Busby Armadale West Australia (UTC+0800) ..
Re: What tool(s) reports OS buss width, which processor present?
Hello, On Wed, Aug 21, 2024 at 07:52:14AM -0400, Greg Wooledge wrote: > It's extremely likely that whatever arch /bin/ls uses is the "primary" > arch for the system. It works on every Linux system I've encountered, > even if the kernel doesn't match it. > > Of course, for Debian specifically, there's also > > dpkg --print-architecture > > If that agrees with file /bin/ls, then you've got one more level of trust. I'm sure that if a reader has done the following they would know and remember, but I do have some i386 Debian hosts which were partially cross-graded to amd64 only as far as running the amd64 kernel while leaving all of the user land and the primary dpkg architecture as i386. This is a supported configuration. In that case "uname -a" reports the amd64 kernel correctly, while "file /bin/ls" and "dpkg --print-architecture" both still report i386! 😀 Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: What tool(s) reports OS buss width, which processor present?
On Wed, 21 Aug 2024, Richard Owlett wrote: > I know I've asked this before, but couldn't thread. > /etc/debian_version reports release active, but I need to know 32 or 64 bit. > TIA > dmidecode
Re: What tool(s) reports OS buss width, which processor present?
This is an edit/resend. Originally I tried to reconstruct the initial login of the day, but brain fart got things backwards, after the upgrade and reboot. Richard Owlett composed on 2024-08-21 06:34 (UTC-0500): > I know I've asked this before, but couldn't thread. > /etc/debian_version reports release active, but I need to know 32 or 64 bit. Debian GNU/Linux 11 gx28b tty3 gx28b login: root Password: Linux gx28b 5.10.0-30-686 #1 SMP Debian 5.10.218-1 (2024-06-01) i686 Have a lot of GX28B fun... Last login: Wed Jun 16 22:44:18 EDT 2024 on tty2 root@gx28b:~# uname -a Linux gx28b 5.10.0-32-686 #1 SMP Debian 5.10.223-1 (2024-08-10) i686 GNU/Linux root@gx28b:~# ... # inxi -CSz System: Kernel: 5.10.0-32-686 arch: i686 bits: 32 Desktop: TDE (Trinity) v: R14.1.2 Distro: Debian GNU/Linux 11 (bullseye) CPU: Info: single core model: Intel Pentium 4 bits: 32 type: MT cache: L2: 1024 KiB Speed (MHz): avg: 2793 min/max: N/A cores: 1: 2793 2: 2793 # lscpu Architecture: i686 CPU op-mode(s): 32-bit Byte Order: Little Endian Address sizes:36 bits physical, 32 bits virtual CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 2 Core(s) per socket: 1 Socket(s):1 Vendor ID:GenuineIntel CPU family: 15 Model:4 Model name: Intel(R) Pentium(R) 4 CPU 2.80GHz Stepping: 1 CPU MHz: 2793.078 BogoMIPS: 5586.15 L1d cache:16 KiB L2 cache: 1 MiB Vulnerability... # -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: What tool(s) reports OS buss width, which processor present?
Richard Owlett composed on 2024-08-21 06:34 (UTC-0500): > I know I've asked this before, but couldn't thread. > /etc/debian_version reports release active, but I need to know 32 or 64 bit. Debian GNU/Linux 11 gx28b tty3 gx28b login: root Password: Linux gx28b 5.10.0-32-686 #1 SMP Debian 5.10.223-1 (2024-08-10) i686 Have a lot of GX28B fun... Last login: Wed Jun 16 22:44:18 EDT 2024 on tty2 root@gx28b:~# uname -a Linux gx28b 5.10.0-32-686 #1 SMP Debian 5.10.223-1 (2024-08-10) i686 GNU/Linux root@gx28b:~# ... # inxi -CSz System: Kernel: 5.10.0-32-686 arch: i686 bits: 32 Desktop: TDE (Trinity) v: R14.1.2 Distro: Debian GNU/Linux 11 (bullseye) CPU: Info: single core model: Intel Pentium 4 bits: 32 type: MT cache: L2: 1024 KiB Speed (MHz): avg: 2793 min/max: N/A cores: 1: 2793 2: 2793 # lscpu Architecture: i686 CPU op-mode(s): 32-bit Byte Order: Little Endian Address sizes:36 bits physical, 32 bits virtual CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 2 Core(s) per socket: 1 Socket(s):1 Vendor ID:GenuineIntel CPU family: 15 Model:4 Model name: Intel(R) Pentium(R) 4 CPU 2.80GHz Stepping: 1 CPU MHz: 2793.078 BogoMIPS: 5586.15 L1d cache:16 KiB L2 cache: 1 MiB Vulnerability... # -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: What tool(s) reports OS buss width, which processor present?
On Wed, Aug 21, 2024 at 13:39:22 +0200, to...@tuxteam.de wrote: > On Wed, Aug 21, 2024 at 06:34:30AM -0500, Richard Owlett wrote: > > I know I've asked this before, but couldn't thread. > > /etc/debian_version reports release active, but I need to know 32 or 64 bit. > > TIA > > uname -a > > This tells you the *kernel* version. Note that for most architectures, > the 64 bit version can run 32 bit applications fine if you make sure to > have the libs installed. > > So "the release 'is' 64 bit" or "... 32 bit" is misleading. I've always favored "file /bin/ls" to get the architecture. hobbit:~$ file /bin/ls /bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=15dfff3239aa7c3b16a71e6b2e3b6e4009dab998, for GNU/Linux 3.2.0, stripped It's extremely likely that whatever arch /bin/ls uses is the "primary" arch for the system. It works on every Linux system I've encountered, even if the kernel doesn't match it. Of course, for Debian specifically, there's also dpkg --print-architecture If that agrees with file /bin/ls, then you've got one more level of trust.
Re: What tool(s) reports OS buss width, which processor present?
On 08/21/2024 06:39 AM, to...@tuxteam.de wrote: On Wed, Aug 21, 2024 at 06:34:30AM -0500, Richard Owlett wrote: I know I've asked this before, but couldn't thread. /etc/debian_version reports release active, but I need to know 32 or 64 bit. TIA uname -a This tells you the *kernel* version. Note that for most architectures, the 64 bit version can run 32 bit applications fine if you make sure to have the libs installed. So "the release 'is' 64 bit" or "... 32 bit" is misleading. Cheers Yes BUT I have hardware which is 64 bit but at different has been running both 32 and 64 bit Debian. I need to know which was active now. Thanks
DUH - was [Re: What tool(s) reports OS buss width, which processor present?]
On 08/21/2024 06:34 AM, Richard Owlett wrote: I know I've asked this before, but couldn't thread. /etc/debian_version reports release active, but I need to know 32 or 64 bit. TIA Just finished coffee - inspiration I use MATE just checked Application->System Tools->Mate System Monitor I tells all ;) It's not the answer I received before but is MATE specific. The answer I had been given depended only on Debian itself. Sorry for the noise.
Re: What tool(s) reports OS buss width, which processor present?
On 2024-08-21 19:34, Richard Owlett wrote: I know I've asked this before, but couldn't thread. /etc/debian_version reports release active, but I need to know 32 or 64 bit. TIA maybe this? $ uname -a Thanks -- https://wespeng.pages.dev/
Re: What tool(s) reports OS buss width, which processor present?
On Wed, Aug 21, 2024 at 06:34:30AM -0500, Richard Owlett wrote: > I know I've asked this before, but couldn't thread. > /etc/debian_version reports release active, but I need to know 32 or 64 bit. > TIA uname -a This tells you the *kernel* version. Note that for most architectures, the 64 bit version can run 32 bit applications fine if you make sure to have the libs installed. So "the release 'is' 64 bit" or "... 32 bit" is misleading. Cheers -- t signature.asc Description: PGP signature
What tool(s) reports OS buss width, which processor present?
I know I've asked this before, but couldn't thread. /etc/debian_version reports release active, but I need to know 32 or 64 bit. TIA
Re: which package to file a bug report ?
On Tue Feb 27, 2024 at 7:12 AM GMT, Frank Weißer wrote: > So we are at my original question: Which package to file a bug report ? Package "debian-installer", I think; and/or submit an installation report, which can be done with reportbug against the "installation-report" pseudo package. See <https://d-i.debian.org/manual/en.amd64/ch05s04.html#submit-bug> -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: which package to file a bug report ?
Marco Moock: Am Fri, 23 Feb 2024 13:59:41 +0100 schrieb Frank Weißer : The installer does format it as ext4, but shows ext2 and places that in fstab, what ends up in emergency mode. That's why I'm here That is definitely a bug. So we are at my original question: Which package to file a bug report ? readU Frank
Re: which package to file a bug report ?
Am Fri, 23 Feb 2024 13:59:41 +0100 schrieb Frank Weißer : > First of all: I use german during installation; but I doubt that is > relevant. Try to reproduce it in English if you like. > Marco Moock: > > Am 22.02.2024 schrieb Frank Weißer : > > > >> I only choose ext2 for formatting the encrypted partition, because > >> nothing else is offered. > > > > That is really strange. If I did install Debian 12, it offered me a > > list of different file systems, including ext2/3/4. > > > It does on non-crypt partitions, but not if I choose 'physical volume > for encryption' there; then afterwards I only have the choices to use > it as ext2, swap or lvm or leave it unused for the encrypted > partition. I chose manual partitioning and I created the LUKS container manually and then created an ext4 partition inside. > >> Despite that the partition in fact is getting formatted ext4, so > >> the entry ext2 in /etc/fstab leads into emergency mode. > > > > Does the installer format it as ext4, but shows ext2 and places > > that in fstab? > > Or do you format it manually? > > > The installer does format it as ext4, but shows ext2 and places that > in fstab, what ends up in emergency mode. That's why I'm here That is definitely a bug.
Re: which package to file a bug report ?
First of all: I use german during installation; but I doubt that is relevant. Marco Moock: Am 22.02.2024 schrieb Frank Weißer : I only choose ext2 for formatting the encrypted partition, because nothing else is offered. That is really strange. If I did install Debian 12, it offered me a list of different file systems, including ext2/3/4. It does on non-crypt partitions, but not if I choose 'physical volume for encryption' there; then afterwards I only have the choices to use it as ext2, swap or lvm or leave it unused for the encrypted partition. Despite that the partition in fact is getting formatted ext4, so the entry ext2 in /etc/fstab leads into emergency mode. Does the installer format it as ext4, but shows ext2 and places that in fstab? Or do you format it manually? The installer does format it as ext4, but shows ext2 and places that in fstab, what ends up in emergency mode. That's why I'm here
Re: which package to file a bug report ?
Am 22.02.2024 schrieb Frank Weißer : > I only choose ext2 for formatting the encrypted partition, because > nothing else is offered. That is really strange. If I did install Debian 12, it offered me a list of different file systems, including ext2/3/4. > Despite that the partition in fact is getting formatted ext4, so the > entry ext2 in /etc/fstab leads into emergency mode. Does the installer format it as ext4, but shows ext2 and places that in fstab? Or do you format it manually? > I think the partitioning tool in installer should offer to format the > encrypted partition in ext4, as LUKS (?) does, instead of ext2 and > must write ext4 to /etc/fstab, as this is, how it ends up. LUKS is only a container and doesn't care about the file system inside. After opening it, it is a file under /dev/mapper that can be formatted like /dev/sdXY.
Re: which package to file a bug report ?
Marco Moock: Am 22.02.2024 um 13:18:48 Uhr schrieb Frank Weißer: I use to encrypt my swap and /var/tmp partitions during installation. That is LUKS. the partition tool in debian installer offers me randomized keys for that and has 'delete partition' set to 'yes', which costs lot of time, not necessary on new hdd/ssd and - my opinion - on randomized keys. I propose switching to 'no', when selecting randomized keys. Why? A user can rather easy select what he wants. As I said: My opinion; if you miss setting 'no' you have to wait a lot of time... Further I can select ext2 or swap for partition format. That is really strange. swap is only for the special-purpose swap partition. Yes, I choose it for the swap partition I use ext2 for /var/tmp, but - in /etc/crypttab the marker 'tmp' is missing for the /var/tmp partition Which marker? This one: frank@pc:~$ cat /etc/crypttab sda4_crypt /dev/sda4 /dev/urandom cipher=aes-xts- plain64,size=256,swap,discard sda5_crypt /dev/sda5 /dev/urandom cipher=aes-xts- plain64,size=256,tmp,discard ^^^ crypttab is only for decrypting the partition and creating a device file for the encrypted one. - in /etc/fstab ext2 is set instead of ext4, that cryptsetup defaults to. So on reboot I end up in emergency mode. If you format it in ext2, choose that. Or was that an automatic decision by the installer? I only choose ext2 for formatting the encrypted partition, because nothing else is offered. Despite that the partition in fact is getting formatted ext4, so the entry ext2 in /etc/fstab leads into emergency mode. I think the partitioning tool in installer should offer to format the encrypted partition in ext4, as LUKS (?) does, instead of ext2 and must write ext4 to /etc/fstab, as this is, how it ends up.
Re: which package to file a bug report ?
Am 22.02.2024 um 13:18:48 Uhr schrieb Frank Weißer: > I use to encrypt my swap and /var/tmp partitions during installation. That is LUKS. > the partition tool in debian installer offers me randomized keys for > that and has 'delete partition' set to 'yes', which costs lot of > time, not necessary on new hdd/ssd and - my opinion - on randomized > keys. I propose switching to 'no', when selecting randomized keys. Why? A user can rather easy select what he wants. > Further I can select ext2 or swap for partition format. That is really strange. swap is only for the special-purpose swap partition. > I use ext2 for /var/tmp, but > - in /etc/crypttab the marker 'tmp' is missing for the /var/tmp > partition Which marker? crypttab is only for decrypting the partition and creating a device file for the encrypted one. > - in /etc/fstab ext2 is set instead of ext4, that cryptsetup defaults > to. So on reboot I end up in emergency mode. If you format it in ext2, choose that. Or was that an automatic decision by the installer? -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org
which package to file a bug report ?
Hello! I use to encrypt my swap and /var/tmp partitions during installation. the partition tool in debian installer offers me randomized keys for that and has 'delete partition' set to 'yes', which costs lot of time, not necessary on new hdd/ssd and - my opinion - on randomized keys. I propose switching to 'no', when selecting randomized keys. Further I can select ext2 or swap for partition format. I use ext2 for /var/tmp, but - in /etc/crypttab the marker 'tmp' is missing for the /var/tmp partition - in /etc/fstab ext2 is set instead of ext4, that cryptsetup defaults to. So on reboot I end up in emergency mode. What package have I to file the bug report against? Please apologize my poor english. Kind regards readU Frank
Re: Determining which file is at a given LBA offset; was: HDD error: Current_Pending_Sector
Hi, On Tue, Feb 20, 2024 at 07:53:38PM -0500, Default User wrote: > Note: I occurs to me that another idea would be to simply delete all > files from the "bad" drive, then rsync everything fresh from the "good" > drive back onto the "bad" drive. You can do it in one step with rsync --delete … which will delete anything that doesn't exist on the source. > IIUC, that would the cause the "bad" sector to be retired, and replaced > by a "good" sector. Yes, a lot of the time a new write is successful and when it's not it will be remapped. As long as the remapped sector count doesn't keep going up I'd be fairly comfortable in continuing to use the drive (assuming backups exist) s while longer. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Determining which file is at a given LBA offset; was: HDD error: Current_Pending_Sector
On Tue, 2024-02-20 at 21:36 +, Michael Kjörling wrote: > On 20 Feb 2024 12:51 -0500, from hunguponcont...@gmail.com (Default > User): > > But since the sector already can not be read, How can it be re- > > written > > to a "good" sector? > > Generally, it can't. It will be remapped if necessary when something > else is written to that sector. > > > > If I knew which file (if any) is using the bad sector, I could try > > just > > deleting that file from the "bad" drive, then copy the same file > > over > > from the "Good" drive, at which time the bad sector "should" be > > retired, and replaced by a good sector. > > Assuming ext[234]fs, it looks like you can use tune2fs, udisks and > debugfs to determine the pathname to the file at a given LBA offset. > See > http://www.randomnoun.com/wp/2013/09/12/determining-the-file-at-a-specific-vmdk-offset/ > Hi, Michael! I forgot to say that the filesystem of the "bad" drive is a single partition, formatted as ext4. And the sector and block sizes both seem to be 512b. Per sudo fdisk -l /dev/sdb: Disk /dev/sdb: 3.64 TiB, 4000752599040 bytes, 7813969920 sectors Disk model: My Passport 2627 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: ---- Device StartEndSectors Size Type /dev/sdb1 2048 7813967871 7813965824 3.6T Linux filesystem - Regarding: >. . . it looks like you can use tune2fs, udisks and >debugfs to determine the pathname to the file at a given LBA offset. >See >http://www.randomnoun.com/wp/2013/09/12/determining-the-file-at-a-specific-vmdk-offset/ >that could be a little above my current level of competence. But I >will try to read up on it. Note: I occurs to me that another idea would be to simply delete all files from the "bad" drive, then rsync everything fresh from the "good" drive back onto the "bad" drive. IIUC, that would the cause the "bad" sector to be retired, and replaced by a "good" sector. That might be easier than everything else mentioned so far.
Re: Determining which file is at a given LBA offset; was: HDD error: Current_Pending_Sector
On 20 Feb 2024 12:51 -0500, from hunguponcont...@gmail.com (Default User): > But since the sector already can not be read, How can it be re-written > to a "good" sector? Generally, it can't. It will be remapped if necessary when something else is written to that sector. > If I knew which file (if any) is using the bad sector, I could try just > deleting that file from the "bad" drive, then copy the same file over > from the "Good" drive, at which time the bad sector "should" be > retired, and replaced by a good sector. Assuming ext[234]fs, it looks like you can use tune2fs, udisks and debugfs to determine the pathname to the file at a given LBA offset. See http://www.randomnoun.com/wp/2013/09/12/determining-the-file-at-a-specific-vmdk-offset/ -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Wine in bullseye, which way to go?
Am 02.02.2024 um 15:10:32 Uhr schrieb Greg Wooledge: > It's dying, I would say. Not all the way dead just yet. That's why I think it's time to change to amd64 before it is completely dead. > The next release will not offer an *installer* for i386, but upgrades > from Debian 12 i386 to Debian 13 i386 might continue to work. IIRC those packages will still exist for backwards compatibility for certain application, but I read the rumor that no current i386 kernel will be available. -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org
Re: Wine in bullseye, which way to go?
On 2/2/24 9:10 PM, Greg Wooledge wrote: I am not sure what do you mean by "install that architecture". I have been using i386 versions of Debian, and I do not plan to reinstall it now just because the CPU may allow that. At some point, you will have to make a decision. i386 is going to stop being supported sooner or later. Yeah, I know that. Until then I will try to get the most out of this i386 installation as-is. In any case, I managed to get rid of some 250+ amd64 packages that came with pretty useless wine (5.0.3-3) installation from the bullseye repo. After deinstalling wine & related software (in Synaptic), I ran apt-get update, apt-get upgrade, and apt autoremove. It freed cca 1GB. After reboot, all was clean, so I decided to go with wine via WineHQ. I followed their published procedure for bullseye installation, and after a while it ended up with wine version 9, which for now seems functional. Will update the list in days to come ... Misko
Re: Wine in bullseye, which way to go?
On Fri, Feb 2, 2024 at 2:59 PM Marco Moock wrote: > Am 01.02.2024 um 18:03:47 Uhr schrieb sko...@uns.ac.rs: > > > I am not sure what do you mean by "install that architecture". I have > > been using i386 versions of Debian, and I do not plan to reinstall it > > now just because the CPU may allow that. So instead, I ask whether it > > was expected and properly when Synaptic installed lots of 64-bit > > stuff during Wine installation from repo. Was it ok or not? Or shall > > I remove it and follow instructions from WineHQ website? > > According to documentation I found in the internet, it is possible to > upgrade a Debian system to the amd64 architecture. > Maybe do that, but do a full backup before. > > i386 is dead for Debian, the next release won't be available for i386. > It is about time i386 is killed off. 64bit processors have been in production for over 20 years now. I am all for getting the most out of hardware but considering you can get a Intel Core2 Laptop with 4GB of RAM for less that $100 refurbished there is no real reason to keep i386 around. As long as you have a i386 kernel, you can't use amd64 software on it. > > -- > Gruß > Marco > > Spam und Werbung bitte an ichschickerekl...@cartoonies.org > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Wine in bullseye, which way to go?
On Fri, Feb 02, 2024 at 08:59:18PM +0100, Marco Moock wrote: > According to documentation I found in the internet, it is possible to > upgrade a Debian system to the amd64 architecture. That isn't an upgrade, and it isn't a supported operation. Some people have *done* it, but it's very much at-your-own-risk. > Maybe do that, but do a full backup before. I wouldn't recommend it, certainly not for someone who's operating with less than a full understanding of the situation. > i386 is dead for Debian, the next release won't be available for i386. It's dying, I would say. Not all the way dead just yet. The next release will not offer an *installer* for i386, but upgrades from Debian 12 i386 to Debian 13 i386 might continue to work. That bears its own risks. Support for i386 is likely to be less than full. Things will probably start breaking and not getting fixed, more and more often as the years roll on, until it's officially declared dead. > As long as you have a i386 kernel, you can't use amd64 software on it. This is true. > Am 01.02.2024 um 18:03:47 Uhr schrieb sko...@uns.ac.rs: > > > I am not sure what do you mean by "install that architecture". I have > > been using i386 versions of Debian, and I do not plan to reinstall it > > now just because the CPU may allow that. At some point, you will have to make a decision. i386 is going to stop being supported sooner or later.
Re: Wine in bullseye, which way to go?
Am 01.02.2024 um 18:03:47 Uhr schrieb sko...@uns.ac.rs: > I am not sure what do you mean by "install that architecture". I have > been using i386 versions of Debian, and I do not plan to reinstall it > now just because the CPU may allow that. So instead, I ask whether it > was expected and properly when Synaptic installed lots of 64-bit > stuff during Wine installation from repo. Was it ok or not? Or shall > I remove it and follow instructions from WineHQ website? According to documentation I found in the internet, it is possible to upgrade a Debian system to the amd64 architecture. Maybe do that, but do a full backup before. i386 is dead for Debian, the next release won't be available for i386. As long as you have a i386 kernel, you can't use amd64 software on it. -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org
Re: Wine in bullseye, which way to go?
> Am 01.02.2024 schrieb sko...@uns.ac.rs: > >> CPU op-mode(s): 32-bit, 64-bit > Model name: Pentium(R) Dual-Core CPU T4500 > > That processor can run amd64 Debian, so install that architecture. > > I am not sure what do you mean by "install that architecture". I have been using i386 versions of Debian, and I do not plan to reinstall it now just because the CPU may allow that. So instead, I ask whether it was expected and properly when Synaptic installed lots of 64-bit stuff during Wine installation from repo. Was it ok or not? Or shall I remove it and follow instructions from WineHQ website?
Re: Wine in bullseye, which way to go?
Am 01.02.2024 schrieb sko...@uns.ac.rs: > CPU op-mode(s): 32-bit, 64-bit Model name: Pentium(R) Dual-Core CPU T4500 That processor can run amd64 Debian, so install that architecture.
Re: Wine in bullseye, which way to go?
> Am 01.02.2024 schrieb Miroslav Skoric : > >> This time I was puzzled when noticed that Synaptic installed lots of >> amd64 packages even though my system is i386. > > Run > uname -a > lscpu > > and post it here. > > If your system is i386 only, amd64 software can't run on it. > Remove that architecture from dpkg. > > uname -a Linux localhost 5.10.0-27-686 #1 SMP Debian 5.10.205-2 (2023-12-31) i686 GNU/Linux lscpu Architecture: i686 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 36 bits physical, 48 bits virtual CPU(s): 2 On-line CPU(s) list:0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 23 Model name: Pentium(R) Dual-Core CPU T4500 @ 2.30 GHz Stepping: 10 CPU MHz:1316.130 CPU max MHz:2300. CPU min MHz:1200. BogoMIPS: 4588.77 L1d cache: 64 KiB L1i cache: 64 KiB L2 cache: 1 MiB Vulnerability Gather data sampling: Not affected Vulnerability Itlb multihit:KVM: Mitigation: VMX unsupported Vulnerability L1tf: Vulnerable Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled Vulnerability Meltdown: Vulnerable Vulnerability Mmio stale data: Unknown: No mitigations Vulnerability Retbleed: Not affected Vulnerability Spec rstack overflow: Not affected Vulnerability Spec store bypass:Vulnerable Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __u ser pointer sanitization Vulnerability Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected Vulnerability Srbds:Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe nx lm constant_ tsc arch_perfmon pebs bts cpuid aperfmperf p ni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm
Re: Wine in bullseye, which way to go?
Am 01.02.2024 schrieb Miroslav Skoric : > This time I was puzzled when noticed that Synaptic installed lots of > amd64 packages even though my system is i386. Run uname -a lscpu and post it here. If your system is i386 only, amd64 software can't run on it. Remove that architecture from dpkg.
Wine in bullseye, which way to go?
Hi! As I have some Windows software (for ham radio) that does not have adequate Linux versions, I wanted to install Wine and some related packages from the bullseye repository (wine, q4wine, winetricks, playonlinux, etc). By the way, I had Wine with buster earlier, and most Windows software worked more or less flawlessly, but I deinstalled all that software and Wine before I upgraded buster to bullseye. This time I was puzzled when noticed that Synaptic installed lots of amd64 packages even though my system is i386. Also, it removed some packages, and also reported few errors or like. Finally, no Windows software wanted to run, instead q4wine returned "Exit -1" or like. See bellow some details for particular packages installation: (Wine) Removing portaudio19-dev:i386 (19.6.0-1.1) ... Removing libjack-dev (1:0.125.0-3+b1) ... dpkg: libjack0:i386: dependency problems, but removing anyway as you requested: mpv depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however: Package libjack-jackd2-0 is not installed. Package libjack-0.125 is not installed. Package libjack0:i386 which provides libjack-0.125 is to be removed. mplayer depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however: Package libjack-jackd2-0 is not installed. Package libjack-0.125 is not installed. Package libjack0:i386 which provides libjack-0.125 is to be removed. libportaudio2:i386 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however: Package libjack-jackd2-0 is not installed. Package libjack-0.125 is not installed. Package libjack0:i386 which provides libjack-0.125 is to be removed. libfluidsynth2:i386 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however: Package libjack-jackd2-0 is not installed. Package libjack-0.125 is not installed. Package libjack0:i386 which provides libjack-0.125 is to be removed. libavdevice58:i386 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however: Package libjack-jackd2-0 is not installed. Package libjack-0.125 is not installed. Package libjack0:i386 which provides libjack-0.125 is to be removed. libasound2-plugins:i386 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however: Package libjack-jackd2-0 is not installed. Package libjack-0.125 is not installed. Package libjack0:i386 which provides libjack-0.125 is to be removed. gstreamer1.0-plugins-good:i386 depends on libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125; however: Package libjack-jackd2-0 is not installed. Package libjack-0.125 is not installed. Package libjack0:i386 which provides libjack-0.125 is to be removed. Removing libjack0:i386 (1:0.125.0-3+b1) ... Setting up gcc-10-base:amd64 (10.2.1-6) ... Setting up libgcc-s1:amd64 (10.2.1-6) ... Setting up libcrypt1:amd64 (1:4.4.18-4) ... Setting up libc6:amd64 (2.31-13+deb11u7) ... Setting up libgpg-error0:amd64 (1.38-2) ... Setting up libgcrypt20:amd64 (1.8.7-6) ... Setting up liblz4-1:amd64 (1.9.3-2) ... Setting up liblzma5:amd64 (5.2.5-2.1~deb11u1) ... Setting up libzstd1:amd64 (1.4.8+dfsg-2.1) ... Setting up libexpat1:amd64 (2.2.10-2+deb11u5) ... Setting up libgraphite2-3:amd64 (1.3.14-1) ... Setting up liblcms2-2:amd64 (2.12~rc1-2) ... Setting up libpixman-1-0:amd64 (0.40.0-1.1~deb11u1) ... Setting up libcdparanoia0:amd64 (3.10.2+debian-13.1) ... Setting up ipp-usb (0.9.17-3+b4) ... ipp-usb.service is a disabled or a static unit, not starting it. Setting up libvo-amrwbenc0:amd64 (0.1.3-2) ... Setting up libxau6:amd64 (1:1.0.9-1) ... Setting up libraw1394-11:amd64 (2.1.2-2) ... Setting up libkeyutils1:amd64 (1.6.1-2) ... Setting up libgpm2:amd64 (1.20.7-8) ... Setting up libmpg123-0:amd64 (1.26.4-1) ... Setting up libogg0:amd64 (1.3.4-0.1) ... Setting up libspeex1:amd64 (1.2~rc1.2-1.1) ... Setting up libshine3:amd64 (3.1.1-2) ... Setting up libtwolame0:amd64 (0.4.0-2) ... Setting up libdatrie1:amd64 (0.2.13-1) ... Setting up libgsm1:amd64 (1.0.18-2) ... Setting up libvisual-0.4-0:amd64 (0.4.0-17) ... Setting up libcapi20-3:amd64 (1:3.27-3+b1) ... Setting up libglvnd0:amd64 (1.3.2-1) ... Setting up libssl1.1:amd64 (1.1.1w-0+deb11u1) ... Setting up libaom0:amd64 (1.0.0.errata1-3+deb11u1) ... Setting up libbrotli1:amd64 (1.0.9-2+b2) ... Setting up libsqlite3-0:amd64 (3.34.1-3) ... Setting up libsasl2-modules:amd64 (2.1.27+dfsg-2.1+deb11u1) ... Setting up libffi7:amd64 (3.3-6) ... Setting up libvkd3d1:i386 (1.1-5) ... Setting up libnghttp2-14:amd64 (1.43.0-1+deb11u1) ... Setting up libunistring2:amd64 (0.9.10-4) ... Setting up libdeflate0:amd64 (1.7-1) ... Setting up zlib1g:amd64 (1:1.2.11.dfsg-2+deb11u2) ... Setting up libidn2-0:amd64 (2.3.0-5) ... Setting up libcom-err2:amd64 (1.46.2-2) ... Setting up libgomp1:amd64 (10.2.1-6) ... Setting up libxvidcore4:amd64 (2:1.3.7-1) ... Setting up libunwind8:amd64 (1.3.2-2) ... Setting up libx264-160:amd64 (2:0.160.3011+gitcde9a93-2.1
Re: Encrypted partiotions - which files related?
On Mon 29 Jan 2024 at 16:12:30 (+0100), Hans wrote: > > That appears to be too much overhead to me... virtual machines (for > > server as full OS) seem much more appropriate to me, in particular as > > differences between in-VM and physical devices are pretty much (not > > completely, though!) abstracted away these days. > > non no, that is exactly, what I was not wanted. My goal was to have my > environment completely and easily portable. Without the need of having > virtualkbox or anything else: just plugin the usb-stick in ANY computer I > want, and I have everything available. Instead of this, I could carry my > notebook with me, but that is not what I want. Be prepared, also in any > situations. And a usb-stick you can always carry with you. That was the idea. > > And except this little annoying question at boot - which is only annoying and > does no harm - everyt6hing is running perfectly to my needs. > > Oh, and I believe, you are right, the cuase of this issue might really be the > initrd (which maye can be configured somehow) and then chosen as the initrd, > which is copied to the livesystem. Maybe I will take a look at this. > > However, it looks like no one else had other ideas, which are the files > responsible, that the boot process is discovering the harddrive and wants to > decrypt it. Well you haven't exactly given a lot of information to go on. For example, before you hijacked your own thread (OT: Is there any size limit for ISO's?), you said that you only got the prompts when the stick booted in the "home" PC, not "foreign" ones. That didn't make it into this thread, but one about ISOs, which I had already deleted days earlier but happened to have skimmed. https://lists.debian.org/debian-user/2024/01/msg01218.html Not a lot here about which filesystems are encrypted, what's in crypttab, fstab, the initrd, etc. and so on, but just some narrative. > If no one else has any ideas in the future, I think, we should declare this > issue as closed. > > I got a workaround, this is well enough for me. > > Thank you and all others for your help! Cheers, David.
Re: Encrypted partiotions - which files related?
Hi Arno, > > That appears to be too much overhead to me... virtual machines (for > server as full OS) seem much more appropriate to me, in particular as > differences between in-VM and physical devices are pretty much (not > completely, though!) abstracted away these days. > non no, that is exactly, what I was not wanted. My goal was to have my environment completely and easily portable. Without the need of having virtualkbox or anything else: just plugin the usb-stick in ANY computer I want, and I have everything available. Instead of this, I could carry my notebook with me, but that is not what I want. Be prepared, also in any situations. And a usb-stick you can always carry with you. That was the idea. And except this little annoying question at boot - which is only annoying and does no harm - everyt6hing is running perfectly to my needs. Oh, and I believe, you are right, the cuase of this issue might really be the initrd (which maye can be configured somehow) and then chosen as the initrd, which is copied to the livesystem. Maybe I will take a look at this. However, it looks like no one else had other ideas, which are the files responsible, that the boot process is discovering the harddrive and wants to decrypt it. If no one else has any ideas in the future, I think, we should declare this issue as closed. I got a workaround, this is well enough for me. Thank you and all others for your help! Best regards Hans
Re: Encrypted partiotions - which files related?
Hello Hans, Am 29.01.2024 um 12:34 schrieb Hans: Am Montag, 29. Januar 2024, 12:16:14 CET schrieb Arno Lehmann: Hi Arno, yes, I saw the option SRCDISK. For my understanding it is used, when you want to mount a an alien system i.e. via network and make a livefile from this. But even I will do so, still all files will be copied to the livefilesystem, this makes no change. Well, I think this is what you can expect when using a tool to essentially copy your running Linux to a DVD image. You asked me, what I want. Simple: I am running KALI-Linux on one of my notebooks· with encrypted partitions. As my KALI got some tools, which need lots of plugins, has added some software NOT in the KALI-repo and got several personal settings, I could not build a livefile system of KALI by using live-build. I'll try to not digress into why you would want to use a heavily modified Kali in the first place, and then copy it to a different media, which probably results in something quite unmaintainable ;-) ... Everything is working perfectly, except this little annoying at boot. So I understand you want the exact same system as you run it on the host, *but* without the file systems mounted. Here we reach the point where I must admit I do not know how bootcdwrite works :-) However, from its documentation, I conclude it essentially puts all system configuration into its target directory tree, but it will have to modify some of it -- for example, if / is mounted from the live file system, a mount point in /etc/fstab for / would be counterproductive. The tool, accordingly, has to modify all the fstab entries for the file systems it copies. That seems to work, as you state above. Also apparently, the underlying block storage setup *is* copied. Your goal seems clear, you do not want that block storage to be accessed, so you'd have tomake sure the necessary setup is *not* copied. Depending on the stack you use, that could be md, lvm, luks, and possible more stuff. Now, where do you draw the line? I, for example, would prefer to have md automatically trying to assemble any RAID it may find, and LVM to kick in, too. Matters of taste put aside -- I think you can use the extra_changes() function in the configuration to mangle the respective configurations according to your needs. Removing entries from fstab and crypttab would possibly be sufficient, but if the created image makes use of your existing initrd, you might have to modify that as well. In that latter case, I would probably decide that the modifications are so invasive, that the idea to call this a "copy" of the origin system is no longer true, and just using a generic live / rescue system may be easier. Besides: Doing so, is a great advantage, as you might agree: I can make a livesystem from a server, then boot it and now can dangerousless test different configurations, can install packages, can test special settings and so on. Just without to harm any productive system. That appears to be too much overhead to me... virtual machines (for server as full OS) seem much more appropriate to me, in particular as differences between in-VM and physical devices are pretty much (not completely, though!) abstracted away these days. If a real, identical piece of hardware is needed for such projects, I would rather invest money than time and still carry the risk to accidentally destroy a production system, which also would, by necessity, be down for whenever I experiment. Which would at least make comparisons of behaviour much more difficult. And after testing, I can easily change the well tested configurations to the productive server! Two advantages, as you see. My views are quite different, but that may be because I'm working too much in environments where lab - staging - production systems are prescribed anyway, and configuration is engineered in labs and eventually deployed through automated systems. Does this make things a little bit clearer? Definitely clearer, but I suspect you'll eventually have to put a lot of your own effort into your final solution, as the general idea is rather specific. Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Re: Encrypted partiotions - which files related?
Am Montag, 29. Januar 2024, 12:16:14 CET schrieb Arno Lehmann: Hi Arno, yes, I saw the option SRCDISK. For my understanding it is used, when you want to mount a an alien system i.e. via network and make a livefile from this. But even I will do so, still all files will be copied to the livefilesystem, this makes no change. You asked me, what I want. Simple: I am running KALI-Linux on one of my notebooks· with encrypted partitions. As my KALI got some tools, which need lots of plugins, has added some software NOT in the KALI-repo and got several personal settings, I could not build a livefile system of KALI by using live-build. Thus my idea, creating a livefile from the running KALI (which I did already successfull with a debian system on another computer) and copy it to a usb- stick by using the dd command. So I created an ISO with about 32GB size, than copied it to a 64GB usb-stick and Voila, I got my own KALI running from usb-stick. Everything is working perfectly, except this little annoying at boot. Besides: Doing so, is a great advantage, as you might agree: I can make a livesystem from a server, then boot it and now can dangerousless test different configurations, can install packages, can test special settings and so on. Just without to harm any productive system. And after testing, I can easily change the well tested configurations to the productive server! Two advantages, as you see. Does this make things a little bit clearer? Best Hans > Hi Hans, > > Am 29.01.2024 um 11:30 schrieb Hans: > > Hi folks, > > > > I created a livefile system with bootcdwrite from a system with encrypted > > partitions. > > > > Everything is working fine, but ... > > Checking the manual for bootcdwrite.conf, I find > > OPTIONS > > SRCDISK > The Variables SRCDISK defines the root of the files that will be copied. > > For example, to build an image from a remote system, export > root-directory with nfs, mount it locally to /mnt/remote and add: > > SRCDISK=/mnt/remote > > > > It is added as prefix to KERNEL, INITRD, DISABLE_CRON and NOT_TO_CD, if > this are relativ paths (without starting "/") > > Default: > > SRCDISK=/ > > > which I understand implies that, by default, bootcdwrite more or less > copying the system you run it on. Thus, the expectation that it should > keep off of your lawn, erm, partitions seems unrealistic. > > On the other hand, you can create a configuration that uses a different > source system, or modifies it. In your case, it appears that you want > some modifications. > > My understanding, however, is that you want modifications going so deep, > that it may be more reasonable to *not* start with your regular system. > Before we try to identify what you'd have to exclude, can you give us an > idea of what your actual goal ist? > > Cheers, > > Arno
Re: Encrypted partiotions - which files related?
Hi Hans, Am 29.01.2024 um 11:30 schrieb Hans: Hi folks, I created a livefile system with bootcdwrite from a system with encrypted partitions. Everything is working fine, but ... Checking the manual for bootcdwrite.conf, I find OPTIONS SRCDISK The Variables SRCDISK defines the root of the files that will be copied. For example, to build an image from a remote system, export root-directory with nfs, mount it locally to /mnt/remote and add: SRCDISK=/mnt/remote It is added as prefix to KERNEL, INITRD, DISABLE_CRON and NOT_TO_CD, if this are relativ paths (without starting "/") Default: SRCDISK=/ which I understand implies that, by default, bootcdwrite more or less copying the system you run it on. Thus, the expectation that it should keep off of your lawn, erm, partitions seems unrealistic. On the other hand, you can create a configuration that uses a different source system, or modifies it. In your case, it appears that you want some modifications. My understanding, however, is that you want modifications going so deep, that it may be more reasonable to *not* start with your regular system. Before we try to identify what you'd have to exclude, can you give us an idea of what your actual goal ist? Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Encrypted partiotions - which files related?
Hi folks, I created a livefile system with bootcdwrite from a system with encrypted partitions. Everything is working fine, but strangely the livefile discovers the encrypted partitions and wants the decryption keys. This is wondering me, because the livefile is running in RAM and should not access the harddrive, encrypted or not. The workaround is, before creating the livefilesystem, I moved /etc/crypttab out of the way. Thus, it already wants to decrypt, but pressing enter for three times (pass an ampty password) let the boot go on. So I searched, which files are related to encrypted partitions, too, to get them also out of the way, but I found none. What did I miss? Any idea or solution, why thje livefile still finds and want to decrypt those partitions? Besides: If I let /etc/crypttab stay, then I must enter the correct password of the partitions during boot in the livefile (which IMO is normal). Thanks for any feedback. Best regards Hans
which keyring to install to access jessie archive?
Hi folks, apparently the jessie archive repository is still alive, but if I try to update the package list there is an error message W: GPG error: http://archive.debian.org/debian jessie Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010 NO_PUBKEY CBF8D6FD518E17E1 I tried installing debian-archive-keyring_2017.5~deb8u1_all.deb debian-archive-keyring_2019.1+deb10u1_all.deb debian-archive-keyring_2021.1.1+deb11u1_all.deb debian-archive-keyring_2023.4_all.deb but neither provides the missing keys. Which debian keyring packages do I have to install to verify Debian packages from the archive repositories? Regards Harri
which poc...@columbus.rr.com
which poc...@columbus.rr.com -- Hindi madali ang maging ako
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
Hi Greg > Sent: Tuesday, December 12, 2023 at 2:43 AM > From: "Greg Wooledge" > To: debian-user@lists.debian.org > Subject: Re: From which kernel should I upgrade my installed Debian to > linux-image-6.1.0-15-amd64? > > On Mon, Dec 11, 2023 at 07:38:02PM +0100, Stella Ashburne wrote: > > Please see Greg's reply to my other post (URL: > > https://lists.debian.org/debian-user/2023/12/msg00640.html). > > > > For your convenience, I quote a section of his reply (see below): > > > > "Yes, because linux-image-amd64 *right now* depends on > > linux-image-6.1.0-15-amd64. Removing linux-image-6.1.0-15-amd64 will > > therefore remove linux-image-amd64." > > > > Removing the buggy linux-image-6.1.0-14-amd64 will also remove the > > metapackage linux-image-amd64. > > This is incorrect. I'm not even sure how you came up with this idea. > Sorry, Greg for having misunderstood your explanation but it's good that you clarified my misconception in this reply of yours. > It's no different from removing any > other old kernel images. So long as they're not the current one, they > can be removed freely. > The above two statements have clarified my misunderstanding. Thank you. Best wishes. Stella
Re: Issues found in linux-image-6.1.0-15-amd64 6.1.66-1; was: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
On 11 Dec 2023 21:45 -0700, from charlescur...@charlescurley.com (Charles Curley): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057967 And from the looks of that bug report thread, message #72 onwards, there is now a candidate fix. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057967#72 I'll echo the sentiment of Kevin Price in #77: let's hope that a corresponding build can be pushed to Stable soon, indeed. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
On Tue, 12 Dec 2023 04:15:33 + Tom Furie wrote: > Do we know yet which wifi drivers are "troublesome"? I haven't seen > anything concrete yet anywhere. You can read the gory details at Mr. Price's bug report. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057967 -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
Kevin Price writes: > 6.1.0-15 brought not only the ext4-bugfix, but along with it introduced > a terrible new bug: Most computers work fine with -15, except for some > of those that have wifi, depending upon the driver. There was a certain > change in Linux's cfg80211 kernel module, which controls wifi. This very > change was adopted in debian's hastily released 6.1.0-15. Whichever > computer is affected, then not only loses wifi, but becomes virtually > unusable, unable to perform simple tasks, such as even to properly shut > down. So -15 is useless for a number of users. Expect blogposts about > that as well. Do we know yet which wifi drivers are "troublesome"? I haven't seen anything concrete yet anywhere. Cheers, Tom
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
Hey Stella, hey all: Am 11.12.23 um 19:38 schrieb Stella Ashburne: > Thank goodness it only happens once in a blue moon. May I please clarify some basic (mis-)conceptions? There's "linux-image-amd64". This is a metapackage that contains nothing but a constructed dependency upon the latest kernel package, such as now "linux-image-6.1.0-15-amd64". If any debian package A has a dependency upon B, then installing A will make apt install B as well. If you then try to uninstall B, either dpkg will refuse, or apt will offer to uninstall A beforehand. That's the single one purpose metapackages exist for: to make sure you have another package installed.[1] Why does debian provide the metapackage "linux-image-amd64"? That's because every now and then your real kernel package, such as "linux-image-6.1.0-12-amd64" should be updated to "linux-image-6.1.0-13-amd64", or so on. Those are not two versions of the same linux package, but rather they're two seperate packages that may be installed simultaneously, which apt itself will not "update" from one to the other. The best way for debian to ensure everyone has current kernel versions, is to provide a metapackage with a name that doesn't change, such as "linux-image-amd64". That metapackage, when updated, apt will recognize as depending upon (requiring) a previously not installed package, such as "linux-image-6.1.0-13-amd64" Metapackage "linux-image-amd64" version... 6.1.52-1 depends on linux-image-6.1.0-12-amd64 6.1.55-1 depends on linux-image-6.1.0-13-amd64 6.1.64-1 depends on linux-image-6.1.0-14-amd64 (nasty!) 6.1.66-1 depends on linux-image-6.1.0-15-amd64 Also there are similar "dependencies" in place and in sync with the kernel one, such as another metapackage "linux-headers-amd64". Also there might be other mechnisms (autoremove) in place for the purpose of uninstalling your outdated kernels for disk space, but they spare the current one as well as its one predecessor as your backup boot option, just in case any update might go bad. (blue moon) Everything will be fine. (fingers crossed) If you happened to update bookworm last weekend, you might have caught "linux-image-amd64" in version 6.1.64-1. That would have intentionally pulled and installed the accidentally very dangerous "linux-image-6.1.0-14-amd64". Let's call it "nasty". Please make very sure to never boot that. It is known to possibly fry your ext4, potentially destroying all your data. That's why debian interrupted the 12.3 point-release process very quickly. Unprecedented? I'm certain there're plenty blog posts and maybe official statements about that to come, about this one-in-a-IDK-glitch. (Andy had suggested a decade, that seems about correct.) Could anyone have installed, or even booted nasty 6.1.0-14 in the meantime? Yes. I have, for instance. By chance it didn't hurt me this time, but I'm not betting again. Re your situation: To make sure, I highly recommend uninstalling nasty "linux-image-6.1.0-14-amd64", provided that you have another functioning kernel version. But if your metapackage "linux-image-amd64" is still version 6.1.64-1, that would get uninstalled as well. Result: You'd no longer receive automatic kernel updates, very bad. So maybe better first update the entire debian, including all the metapackages, and as of now you'll get linux-image-amd64 in version 6.1.66-1. That no longer "depends" upon nasty linux-image-6.1.0-14-amd64, but rathermore -15. (Wait, please read on first!) That's what might happen once in a blue moon at the very most, and hurt noone, hopefully. And then debian rectified it in the middle of the point-release process, by hastily cancelling release 12.3 and replacing it with 12.4. New kernel version is now 6.1.0-15, no more ext4 frying. What could possibly go wrong by hastily releasing a debian kernel? ()brace for impact() 6.1.0-15 brought not only the ext4-bugfix, but along with it introduced a terrible new bug: Most computers work fine with -15, except for some of those that have wifi, depending upon the driver. There was a certain change in Linux's cfg80211 kernel module, which controls wifi. This very change was adopted in debian's hastily released 6.1.0-15. Whichever computer is affected, then not only loses wifi, but becomes virtually unusable, unable to perform simple tasks, such as even to properly shut down. So -15 is useless for a number of users. Expect blogposts about that as well. An unusable kernel (-15) once in a blue moon is no big deal, since you can always boot back into... the... previous... one... Oh, wait. Can you see where this is getting to? Oh no, not -14? So if you're fortunate enough for -15 to be working for you, lucky you, maybe just keep -13 as a backup. I happen to be
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
On Mon, Dec 11, 2023 at 07:38:02PM +0100, Stella Ashburne wrote: > Please see Greg's reply to my other post (URL: > https://lists.debian.org/debian-user/2023/12/msg00640.html). > > For your convenience, I quote a section of his reply (see below): > > "Yes, because linux-image-amd64 *right now* depends on > linux-image-6.1.0-15-amd64. Removing linux-image-6.1.0-15-amd64 will > therefore remove linux-image-amd64." > > Removing the buggy linux-image-6.1.0-14-amd64 will also remove the > metapackage linux-image-amd64. This is incorrect. I'm not even sure how you came up with this idea. If you have linux-image-amd64 version 6.1.66-1, it depends on linux-image-6.1.0-15-amd64 and NOT on linux-image-6.1.0-14-amd64. In this situation, nothing depends on linux-image-6.1.0-14-amd64 so you may remove it without worry. It's no different from removing any other old kernel images. So long as they're not the current one, they can be removed freely.
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
Hi Andy > Sent: Monday, December 11, 2023 at 11:25 PM > From: "Andrew M.A. Cater" > To: debian-user@lists.debian.org > Subject: Re: From which kernel should I upgrade my installed Debian to > linux-image-6.1.0-15-amd64? > > > If you're not currently booted into the erroneous 6.1.0-14 - don't boot into > it and you can safely apt-get remove it (or equivalent). > Your above statement implies strongly that one boots up their device using linux-image-6.1.0-13-amd64 > If you also install linux-image-amd64 if you removed it - you should end > up with 6.1.0-15 and 6.1.0-13 available to you. > Please see Greg's reply to my other post (URL: https://lists.debian.org/debian-user/2023/12/msg00640.html). For your convenience, I quote a section of his reply (see below): "Yes, because linux-image-amd64 *right now* depends on linux-image-6.1.0-15-amd64. Removing linux-image-6.1.0-15-amd64 will therefore remove linux-image-amd64." Removing the buggy linux-image-6.1.0-14-amd64 will also remove the metapackage linux-image-amd64. > This isn't something that happens often - ideally not more than once a > decade - so we haven't had a lot of practice at this. Thank goodness it only happens once in a blue moon. Someone might wish to add to Debian's wiki on how to deal with the situation of having a buggy kernel made available via the official repos, a few hours later a warning against upgrading to it and the release team failing to pull it out of the official repos. Best wishes. Stella
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
On Mon, Dec 11, 2023 at 02:25:23PM +0100, Kevin Price wrote: > Am 11.12.23 um 14:16 schrieb Stella Ashburne: > > Suppose I wish to upgrade to linux-image-6.1.0-15-amd64. > > If that were the case, or maybe better to a newer one. > > > Should I do it after booting my device into > > (1) linux-image-6.1.0-14-amd64 (the problematic kernel) > > NO. Don't ever boot that as it might then toast your ext4. > > > (2) linux-image-6.1.0-13-amd64 (which precedes the buggy one) > > Yes. > > > (3) doesn't matter which kernel to upgrade from > > Yes, it largely doesn't matter, apart from the exception above. > > HTH > -- > Kevin Price > If, this afternoon (UK timezone), you do a full upgrade - you'll get 6.1.0-15 and that's fine. If you're not currently booted into the erroneous 6.1.0-14 - don't boot into it and you can safely apt-get remove it (or equivalent). If you also install linux-image-amd64 if you removed it - you should end up with 6.1.0-15 and 6.1.0-13 available to you. This isn't something that happens often - ideally not more than once a decade - so we haven't had a lot of practice at this. On average, it's OK to just upgrade to the next sequentially numbered kernel and reboot. This once, it isn't. All the very best, as ever, Andy Cater [amaca...@debian.org]
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
Am 11.12.23 um 14:16 schrieb Stella Ashburne: > Suppose I wish to upgrade to linux-image-6.1.0-15-amd64. If that were the case, or maybe better to a newer one. > Should I do it after booting my device into > (1) linux-image-6.1.0-14-amd64 (the problematic kernel) NO. Don't ever boot that as it might then toast your ext4. > (2) linux-image-6.1.0-13-amd64 (which precedes the buggy one) Yes. > (3) doesn't matter which kernel to upgrade from Yes, it largely doesn't matter, apart from the exception above. HTH -- Kevin Price
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
On Mon, Dec 11, 2023 at 02:16:39PM +0100, Stella Ashburne wrote: > (3) doesn't matter which kernel to upgrade from That.
From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
Hi As of now, I'm quite hesistant to upgrade my installed Debian Bookworm to linux-image-6.1.0-15-amd64 as there are two users who reported they have problems with it (cf. https://lists.debian.org/debian-user/2023/12/msg00570.html and https://lists.debian.org/debian-user/2023/12/msg00607.html) However.. Suppose I wish to upgrade to linux-image-6.1.0-15-amd64. Should I do it after booting my device into (1) linux-image-6.1.0-14-amd64 (the problematic kernel) or (2) linux-image-6.1.0-13-amd64 (which precedes the buggy one) or (3) doesn't matter which kernel to upgrade from I welcome your expert opinions and the reasons for your choice. Best regards. Stella P.S.: I'm sorry to have to ask the above question because this is the first time I have ever encountered the problem of having to upgrade a defective kernel within the space of a day, literally.
[SOLVED] Re: bookworm which repo?
Thanks for the advice. So, bookworm-updates is recommended, bookworm-backports is optional. At upgrade time the documentation said something else (I suppose, because it was an upgrade no fresh installation) Well, the problem is solved. Thanks for the hint. Best Hans > So, should I use all four entries or do you recommend to skip one of it? > > https://wiki.debian.org/SourcesList > > Cheers, > David.
Re: bookworm which repo?
On Sat 04 Nov 2023 at 13:50:34 (+0100), Hans wrote: > A fresh install is showing an entry in /etc/apt/sources.list for > > 1. bookworm > 2. bookworm-security > and > 3. bookworm-updates > > The last one is somehow confusing me, either I missed somethin in the > documentation or soemthing has changed since the release of bookworm. > > Just a question. The first two are clear, but "bookworm-updates" is new for > me. > > Instead of this I entered "bookworm-backports", which was, as the > documentation said, recommended at time of the installation > > However, please note: I did not do a fresh install at the release date of > bookworm, but an upgrade from buster to bookworm, so it might > be, the entry for "bookworm-backports" was recommended at that time. > > So, should I use all four entries or do you recommend to skip one of it? https://wiki.debian.org/SourcesList Cheers, David.
bookworm which repo?
Hi folks, just a little question. A fresh install is showing an entry in /etc/apt/sources.list for 1. bookworm 2. bookworm-security and 3. bookworm-updates The last one is somehow confusing me, either I missed somethin in the documentation or soemthing has changed since the release of bookworm. Just a question. The first two are clear, but "bookworm-updates" is new for me. Instead of this I entered "bookworm-backports", which was, as the documentation said, recommended at time of the installation However, please note: I did not do a fresh install at the release date of bookworm, but an upgrade from buster to bookworm, so it might be, the entry for "bookworm-backports" was recommended at that time. So, should I use all four entries or do you recommend to skip one of it? My system is running fine! Best regards Hans
Re: Which Network Controller Card handling Wi-Fi, Bluetooth, etc., connectivities, is GNU/Linux Approved/certified, and would be (1) compatible with my HP laptop's motherboard, and (2) could replace t
Hello, On Sun, Oct 29, 2023 at 07:04:35PM +0530, Susmita/Rajib wrote: > Dear Mr. Cater, Thank you for your post, re-forming the subject-line > and your query. Why are you reforming Andrew's subject line? It seemed like a very sensible subject line. > I request you not to rename the subject of the thread, as the > continuity of the thread shall be lost and I might not be able to > trace the thread in future. But your subject lines are too long. Can you find even one person besides yourself who thinks that your practice of putting an entire paragraph into a subject line is a sensible email practice compared to the subject that Andrew Cater used, and you rejected? I request that you stop using such lengthy subject lines as they make it hard to quickly determine what any of your emails are actually about - the primary purpose of the subject header. Additionally, I would suggest that if your email software can't cope with the proper threading of emails when their subject line is changed, that you should pick better software for the purpose of reading email. There is no shortage of options that can accomplish the basic task of presenting threads of conversation. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Which Network Controller Card handling Wi-Fi, Bluetooth, etc., connectivities, is GNU/Linux Approved/certified, and would be (1) compatible with my HP laptop's motherboard, and (2) could replace t
Dear Mr. Cater, Thank you for your post, re-forming the subject-line and your query. Since this part is over, please let this subject thread remain closed. I won't post any further messages ion it. It would be a different matter if someone posts on the thread and I am obliged to reply to that query. Please note that the reply your query on the post with the renamed subject: Broadcom WiFi/Bluetooth BCM43142 issues Will be posted on the subject thread: Please help configure to activate Bluetooth networking for "Network controller: Broadcom Inc. and subsidiaries BCM43142 802.11b/g/n (rev 01)" card In fact, I posted my last message without reading yours. Good coincidence, I have partly replied to your query on output on that last message. I request you not to rename the subject of the thread, as the continuity of the thread shall be lost and I might not be able to trace the thread in future. Best wishes, Rajib Etc.
Re: Which Network Controller Card handling Wi-Fi, Bluetooth, etc., connectivities, is GNU/Linux Approved/certified, and would be (1) compatible with my HP laptop's motherboard, and (2) could replace t
I have had a conversation with the Team ThinkPenguin for the wireless N model model. Their USB WiFi dongle is only for WiFi connectivity. Not for Bluetooth. The team has been very transparent with sharing information, and I thank you for letting me know about such an empowering team surviving within the proprietary universe. Since the wl module already has configured and restored the WiFi connectivity for my laptop, I wouldn't require the said dongle. Shortly, I will post for configuring the Bluetooth connectivity for my HP laptop. So your support is all the more expected. Best wishes, Rajib
Re: Which Network Controller Card handling Wi-Fi, Bluetooth, etc., connectivities, is GNU/Linux Approved/certified, and would be (1) compatible with my HP laptop's motherboard, and (2) could replace t
I thank Mr. Butterworth for his kind information on the wireless N model network card. This gives me an opportunity to suggest to the Debian Universe to have similar such internal add-ons and a comprehensive list of internal add-ons be made available to us users, be bought from the open market, rather than the list of only tested laptops at https://wiki.debian.org/InstallingDebianOn#OfficialDocumentation and some external accessories, such as printers, scanners, etc. A fair amount of discussion is on the thread: https://lists.debian.org/debian-user/2021/04/msg00504.html The economic model is sure to survive competition given the sheer number of FSF, GNU/Linux users, including the Debian, Arch, Manjaro, Ubuntu, et al, users all over the world. I have sent an email to ThinkPenguin for the wireless N model model using their Contact webpage. Best wishes, Rajib Etc.
Re: Which Network Controller Card handling Wi-Fi, Bluetooth, etc., connectivities, is GNU/Linux Approved/certified, and would be (1) compatible with my HP laptop's motherboard, and (2) could replace t
On Sat, Oct 28, 2023 at 2:44 PM Susmita/Rajib wrote: > My dear Illustrious Leaders and Senior Members of the debian-user Mailing > List, > > I would again return to my earlier post at: > https://lists.debian.org/debian-user/2023/10/msg00650.html > > That is, the First Mail of this thread with the present Subject. > > I desire a Debian approved list for perfectly compatible > Wireless-Bluetooth Cards. The FSF only has one WiFi adapater approved as free software. It is a wireless N model. https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb > Like the PCI list, with the heading: > DeviceDatabase/PCI - Debian Wiki > at > https://wiki.debian.org/DeviceDatabase/PCI > > Why do I need to return to this thread? Because, unlike what Mr. Cater > advised, in his post: > https://lists.debian.org/debian-user/2023/10/msg00679.html > > the "firmware-b43-installer" isn't suitable for the card that my laptop > has: > > "Network controller: Broadcom Inc. and subsidiaries BCM43142 > 802.11b/g/n (rev 01)" card, > > as the webpage > https://wireless.wiki.kernel.org/en/users/drivers/b43#contact > for the "firmware-b43-installer" mentions. The relevant portions of > the said webpage may please be perused. On the webpage the list with > the following columns has the following entries for the said chipset: > PCI-ID Supported? Chip ID Modes PHY version Alternative > 14e4:4365 no BCM43142 b/g/n LCN40 (r3) wl > > That is, the said card of my laptop isn't supported by the > "firmware-b43-installer". I have already posted a reply to Mr. Cater > with the said information at: > https://lists.debian.org/debian-user/2023/10/msg00846.html > > I am still hoping, despite what Mr.Purgert suggests in his post: > https://lists.debian.org/debian-user/2023/10/msg00654.html, that I > will be able to find a Debian-approved wireless networking card and > that my HP laptop BIOS would allow it to be used instead of the native > wireless card. > > If every effort fails, I will try to procure a Frame.work customisable > laptop for my use. > > Best wishes, > Rajib, > Etc. > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Which Network Controller Card handling Wi-Fi, Bluetooth, etc., connectivities, is GNU/Linux Approved/certified, and would be (1) compatible with my HP laptop's motherboard, and (2) could replace t
Am 28.10.2023 um 17:22:18 Uhr schrieb Susmita/Rajib: > I am still hoping, despite what Mr.Purgert suggests in his post: > https://lists.debian.org/debian-user/2023/10/msg00654.html, that I > will be able to find a Debian-approved wireless networking card and > that my HP laptop BIOS would allow it to be used instead of the native > wireless card. My experience with HP laptops (and most other laptops due to FCC reasons) is that only the devices sold with that model (some models support different modules, e.g. to have more expensive Intel for vPro logo and cheaper Broadcoms). My guess it to look at the HP website to see which NICs were shipped with your laptop, then check how they are supported. If none is good for you, you may think about Expresscard or USB solutions.
Re: Which Network Controller Card handling Wi-Fi, Bluetooth, etc., connectivities, is GNU/Linux Approved/certified, and would be (1) compatible with my HP laptop's motherboard, and (2) could replace t
On Sat, Oct 28, 2023 at 05:22:18PM +0530, Susmita/Rajib wrote: > My dear Illustrious Leaders and Senior Members of the debian-user Mailing > List, > > I would again return to my earlier post at: > https://lists.debian.org/debian-user/2023/10/msg00650.html > > That is, the First Mail of this thread with the present Subject. > Hello Rajib, Please can you reduce the size of your subject line. You can make it much shorter and still informative. > I desire a Debian approved list for perfectly compatible > Wireless-Bluetooth Cards. Like the PCI list, with the heading: > DeviceDatabase/PCI - Debian Wiki > at > https://wiki.debian.org/DeviceDatabase/PCI > There is no definitive list for "perfectly compatible" cards, unfortunately. There is a list of cards that people have found to work but, as noted, HP maintain an allowlist/denylist of cards that *they* approve. > Why do I need to return to this thread? Because, unlike what Mr. Cater > advised, in his post: > https://lists.debian.org/debian-user/2023/10/msg00679.html > > the "firmware-b43-installer" isn't suitable for the card that my laptop has: > > "Network controller: Broadcom Inc. and subsidiaries BCM43142 > 802.11b/g/n (rev 01)" card, > > as the webpage https://wireless.wiki.kernel.org/en/users/drivers/b43#contact > for the "firmware-b43-installer" mentions. The relevant portions of > the said webpage may please be perused. On the webpage the list with > the following columns has the following entries for the said chipset: > PCI-ID Supported? Chip ID Modes PHY version Alternative > 14e4:4365 no BCM43142 b/g/n LCN40 (r3) wl > > That is, the said card of my laptop isn't supported by the > "firmware-b43-installer". I have already posted a reply to Mr. Cater > with the said information at: > https://lists.debian.org/debian-user/2023/10/msg00846.html > Thanks for this. Again, a request - please *don't* address replies primarily to individuals - please address them to the list because the list will archive the relevant information. > I am still hoping, despite what Mr.Purgert suggests in his post: > https://lists.debian.org/debian-user/2023/10/msg00654.html, that I > will be able to find a Debian-approved wireless networking card and > that my HP laptop BIOS would allow it to be used instead of the native > wireless card. > Note that you have been given the solution using module-assistant by someone else on the list. > If every effort fails, I will try to procure a Frame.work customisable > laptop for my use. > That will be a very expensive workaround and you may face delays: I think they have a backlog on orders. You may find also that people have had varying experiences with their Framework - there's a very long post on Debian Planet somewhere with a whole list of plusses and minuses. All the very best, as ever, Andy > Best wishes, > Rajib, > Etc. >
Re: Which Virtual Manager?
On 28 Oct 2023 06:33 -0400, from wande...@fastmail.fm (The Wanderer): > virt-manager Do keep in mind that virt-manager is just _one_ possible front-end for KVM (although perhaps the most common GUI one). AQEMU has already been mentioned in this thread. Technically virsh and friends is another front-end, although a command-line one and quite technical. I'm sure there are other freely available alternatives as well. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Which Network Controller Card handling Wi-Fi, Bluetooth, etc., connectivities, is GNU/Linux Approved/certified, and would be (1) compatible with my HP laptop's motherboard, and (2) could replace t
My dear Illustrious Leaders and Senior Members of the debian-user Mailing List, I would again return to my earlier post at: https://lists.debian.org/debian-user/2023/10/msg00650.html That is, the First Mail of this thread with the present Subject. I desire a Debian approved list for perfectly compatible Wireless-Bluetooth Cards. Like the PCI list, with the heading: DeviceDatabase/PCI - Debian Wiki at https://wiki.debian.org/DeviceDatabase/PCI Why do I need to return to this thread? Because, unlike what Mr. Cater advised, in his post: https://lists.debian.org/debian-user/2023/10/msg00679.html the "firmware-b43-installer" isn't suitable for the card that my laptop has: "Network controller: Broadcom Inc. and subsidiaries BCM43142 802.11b/g/n (rev 01)" card, as the webpage https://wireless.wiki.kernel.org/en/users/drivers/b43#contact for the "firmware-b43-installer" mentions. The relevant portions of the said webpage may please be perused. On the webpage the list with the following columns has the following entries for the said chipset: PCI-ID Supported? Chip ID Modes PHY version Alternative 14e4:4365 no BCM43142 b/g/n LCN40 (r3) wl That is, the said card of my laptop isn't supported by the "firmware-b43-installer". I have already posted a reply to Mr. Cater with the said information at: https://lists.debian.org/debian-user/2023/10/msg00846.html I am still hoping, despite what Mr.Purgert suggests in his post: https://lists.debian.org/debian-user/2023/10/msg00654.html, that I will be able to find a Debian-approved wireless networking card and that my HP laptop BIOS would allow it to be used instead of the native wireless card. If every effort fails, I will try to procure a Frame.work customisable laptop for my use. Best wishes, Rajib, Etc.
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: Which Virtual Manager? Was: EASY way to install packages from trixie/sid to stable?
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 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"?
Re: Which Virtual Manager? Was: EASY way to install packages from trixie/sid to stable?
On Fri, 27 Oct 2023 14:46:52 + Minecraftchest1 wrote: > With Virt-Manager, you should have the option to choose an existing > disk image. It can also create a disk image for you. On which you will have to make partitions and file systems. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
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?
With Virt-Manager, you should have the option to choose an existing disk image. 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. I am not ay my laptop currently, but I can take and share some screenshots later today. On October 27, 2023 9:17:46 AM UTC, The Wanderer wrote: >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 experi
Re: Which Virtual Manager? Was: EASY way to install packages from trixie/sid to stable?
On Fri, Oct 27, 2023 at 05:17:46AM -0400, The Wanderer wrote: > 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.) > People's experience varies: I've used Virtualbox in the past, Hyper-V under Windows and VMWare Workstation - Virt-manager provides as easy a front end to KVM for me. It does help if you select the "Customise configuration" option before beginning install at step 5 of 5 > > 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. > See the "configure before install" which opens this up more - you can also see this by viewing/modifying settings - but you normally have to make sure that the VM is shut down. > (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
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 unreasonable one
