Hi, On 2021-08-01 9:58 a.m., Gunnar Gervin wrote: > I expected that answer. > Debian is still 1/2 of it, but kinda dysfunctional, cos of me & scam > Trying to set up Debian in a VM in another Linux distro, with Chef > So I cannot really see irrelevance > of my question?? Like Nobody here knows how to fix this one, cos it's > slightly out of D. politics? There's no such thing as "Debian Politics" (or what would D.Politics mean, could be useful to put a bit more effort in making your message intelligible for others). What there's present here is a community of user that revolve around the Debian Linux distribution, centered over the Debian distribution. So if you run Distribution XYZ and are trying to get Debian running on a VM, we can help you with the Debian part, not much with setting up the VM or what goes with the underlying OS. Not because of some "politics" or because we are stubborn or stillborn, but because we probably have not much experience with the underlying system. We have interest in Debian and this is what we all use mostly. We've exchanged (me and many others) at least two dozen of messages in the last weeks or so. And still, we don't have a clue if you are running Debian. But, we have gave you chances and tools to straight this out. https://lists.debian.org/debian-user/2021/07/msg01216.html *Here's a short part...* Rather than a back and forth on whether Gunnar's description of the machine is correct, it might be more productive to suggest running some simple, definitive commands like: $ ls /sys/firmware/ acpi dmi efi memmap $ It either includes "efi" (UEFI-booted), or it doesn't (BIOS-booted). $ uname -a Linux ajax 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux $ The kernel architecture is given (x86_64 here). The "arch" command is terser. i686/i586/i486 would indicate an i386 architecture. $ grep address /proc/cpuinfo address sizes : 36 bits physical, 48 bits virtual $ Anything over 32 indicates 64-bit capability, whether or not it is being exploited. A 32-bit processor will only yield: address sizes : 32 bits physical, 32 bits virtual *And here goes another one...* https://lists.debian.org/debian-user/2021/07/msg01240.html Of course I haven't. I see scattered posts (only some) from Gunnar that don't seem to make a lot of sense, followed up by discussion and argument, much of which could be avoided by getting some facts into the posts. Hence my suggestion (snipped) to run $ ls /sys/firmware/ $ uname -a $ grep address /proc/cpuinfo and clarify what type of machine (machines?) is being discussed. Perhaps it's reckless not to have suggested a command proving it's a Debian system. In all of Gunnar's posts, I think I have only seen one report of actual output posted, and I have no idea what the origin of that was, viz: # UNCONFIGURED FSTAB FOR BASE SYSTEM overlay / overlay rw 0 0 tmpfs /tmp tmpfs nosuid,nodev 0 0 /dev/sda1 /mnt/sda1 EXT2 nosuid,nodev,nofail,x-gvfs-show 0 0 /dev/sda3 /mnt/sda3 EXT2 nosuid,nodev,nofail,x-gvfs-show,noauto,x-udisks-auth 0 0 /dev/sda2 none swap sw,x-udisks-auth,noauto 0 0 *Now sorry...* Maybe English is not your main language or there's something else but I have to agree with the writter of this last message. Some your post don't make much sense and take more energy to understand the text themselves than they require to really find any type of computing problem. What is easy to understand for yourself may not be the case for others. In the long term, you'll be the one facing penalties for this as people will just get tired and start ignoring. No one's got obligation here and we are all volunteer doing so for the pleasure of helping others. Even myself, when I take to explain things like I'm doing now. And like I did for the "top posting". Here's some tip... I'll show you some hard to understand in the following post... > Geg > > On Sun, 1 Aug 2021, 16:50 Andrew M.A. Cater, <amacater@einval.com > <mailto:amacater@einval.com>> wrote: > > On Sun, Aug 01, 2021 at 04:30:45PM +0300, Gunnar Gervin wrote: > > Security. > > Rarely discussed in Linux(?).. > > Was scammed recently; naive me let a man w/Bad accent take over my > laptop > > to 'help refund BTC' & make me pay 100$. > > Because of that &/or me in Synaptic bloating (2 many) packages, > which led > > to "1t fix broken packages", "put in Debian 10.9 Netinst cdrom", & > "can't > > find key file" messages (yes, all 3 !). > > After trying "all" workarounds, I installed another, more simple Linux > > distro, built up a new setup of relevant programs to build VM, > containers, > > websites, Debian iso image, & CHEF. > > Which distro - are you still using Debian? > > If not, we can't really help you. Although many of us have run other > distributions in the past, all of the Debian/Ubuntu derivatives do > something slightly different - we can only really help with generic > Debian things. If we offer help with any other distribution, it's > only ever best efforts - Debian derivatives have their own support > infrastructure. > > > Now Chef asks me to give URL to continue setting up a VM etc. > > Plz advise &/or help to do it/this. > > It may not be relevant but the chef and chef-zero packages in Buster > appear > to no longer be packaged in Bullseye - the upcoming release due in > two weeks. > > Ask on a Chef list, perhaps? > > > BR, > > GEG > > All best, as ever, > > Andrew Cater > > > > > On Wed, 21 Jul 2021, 18:59 Dan Ritter, <dsr@randomstring.org > <mailto:dsr@randomstring.org>> wrote: > > > > > Reco wrote: > > > > On Wed, Jul 21, 2021 at 10:51:40AM -0400, Celejar wrote: > > > > Numbers show that I was incorrect. Let's call it "unlikely" > instead of > > > > "rare". Let the popcon graphs speak for themselves: > > > > > > > > https://qa.debian.org/popcon.php?package=firefox-esr > <https://qa.debian.org/popcon.php?package=firefox-esr> > > > > vs > > > > https://qa.debian.org/popcon.php?package=openjdk-11 > <https://qa.debian.org/popcon.php?package=openjdk-11> > > > > > > Standard reminder: popcon vastly over-represents > > > individually-owned laptops and desktops over servers and > > > corporately-owned anything. > > > > > > In this case, individuals are sometimes infected with ransomware > > > by happenstance, but corporates are actually targets. > > > > > > > It won't by itself, of course. One sure way to beat ransomware > is to > > > > take immutable backups (i.e. unmodifiable by host during and > after the > > > > backup is taken), and as recent history shows us - ransomware > victims > > > > apparently do not use this approach. > > > > > > Yes indeed. > > > > > > -dsr- > > > > > > > -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature