Re: Paying Debian contributors (Was Re: Advantages/Disadvantages of Open Source Software)
On 9/16/22 12:05 AM, Maude Summerside wrote: > > On 2022-09-15 17:56, Chuck Zmudzinski wrote: > > On 9/15/2022 11:46 AM, Andy Smith wrote: > >> Hello, > >> > >> On Wed, Sep 14, 2022 at 10:04:48PM -0400, Chuck Zmudzinski wrote: > >>> I am not against giving maintainers like Steve just compensation for the > >>> work they do fixing bugs, and by compensation I mean money. > >> > >> It's a very tricky subject to propose to start paying (some?) people > >> in what was always a volunteer project, to do the same work that > >> others do voluntarily. It has been proposed before, and it did not > >> go down well. Search for "dunc tank debian" to read about that. > >> > >> More recently (since 2014), the Debian LTS effort started paying > >> people to upload fixed Debian packages past the end of the normal > >> release lifetime. This is organised by private company Freexian who > >> accept sponsorship funds and pay developers to do this work for > >> Debian, not out of Debian's own funds. > >> > >> https://www.freexian.com/services/debian-lts.html > >> https://wiki.debian.org/LTS > >> https://wiki.debian.org/LTS/FAQ > >> > >> They do LTS, ELTS and some other limited scope efforts. > >> > >> If you do use Debian LTS maybe you could consider contributing to > >> this? Though I would point out: > >> > >> - It's not going to give you the right to tell people what to work > >> on, how to do it, govern their timescales etc. Sponsors are paying > >> for a certain amount of developer time per month, but Freexian and > >> those developers decide what to work on and how to do it. > >> > >> - At the moment the minimum contribution is €255/year. > >> > >> It could also be interesting to explore individual packaging teams > >> within Debian having Patreon and/or ko-fi accounts or similar. > >> > >> Broadly though, none of these small scale funding ideas are ever > >> going to give you the kind of service you apparently seem to want: > >> to be able to force the developers to work on what you want them to > >> work on, in the way you want them to work on it. I can only ever see > >> that happening in situations where you pay much much more for a > >> bespoke solution. > > > > So I have to pay someone lots of money to fix a problem I already know how > > to fix? > > I don't think you really understand my use case very well. > > > > Cheers > > > > Can you stop complaining and take a minute to go read the code of > conduct, rules regarding the Debian mailing list. > There's no reason to do dual posting. > > WtF have you written myself a personal mail ? I think I did, but it was just an oversight. I am aware of the Code of Conduct, and it also says everyone is to presume good intentions, as far as possible. When I noticed I forgot to reply to list, I sent the message again, I think with a little more detail, to the list also, where I should have sent the message in the first place. BTW, just so everyone is aware, the message I sent is on debian-user, and it is an interesting story about a Debian bug and I don't think it was against the Code of Conduct. Best regards, Chuck
Re: Paying Debian contributors (Was Re: Advantages/Disadvantages of Open Source Software)
On 9/15/22 6:29 PM, Lee wrote: > On 9/15/22, Chuck Zmudzinski wrote: > > > > So I have to pay someone lots of money to fix a problem I already know how > > to fix? > > I don't think you really understand my use case very well. > > I surely don't. If you know how to fix whatever why haven't you fixed > it already? I have it fixed in the distro on one bug, but on another I still have to apply the fix myself because no one in Debian will fix it. Fedora developers also fixed the same bug. I discuss that bug in some other posts here. Please read them before asking me about this again. Cheers, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/15/22 11:45 AM, Maude Summerside wrote: > > On 2022-09-14 23:23, Chuck Zmudzinski wrote: > > On 9/14/2022 11:01 PM, Maude Summerside wrote: > >> > >> On 2022-09-14 21:45, Michael Stone wrote: > >>> On Wed, Sep 14, 2022 at 11:16:00PM +0100, Steve McIntyre wrote: > >>>> I'll be brutally honest: being accused of "possibly malicious" > >>>> unwilligness is *not* a great way to convince overstretched volunteers > >>>> to spend their time on issues. > >>> > >>> Especially when it's an ongoing pattern of discourse. > >>> > >> > >> I think there's many barrier that discourage people from wanting to > >> contribute to many project. I feel some developer use the community as > >> unpaid beta tester but don't go further into accepting contribution. > >> > >> For sure, having managed some project, I have to say that it's hard to > >> accept contribution that will add new functions to as software when > >> these come from a unknown contributor. Not because of being scared of > >> malicious intent (unless the person is really paranoid but that's > >> another story). Simply because adding a new function means having to > >> support it's ongoing development and there's no guarantee that the > >> contributor will do so. Same goes on for code contributed that needs > >> refactoring, that are badly documented, etc. But all this need some good > >> social behavior from the project owner/manager. > > > > As a user of the Debian software and a user of the BTS, I am discouraged not > > because new contributions or functions are being rejected, but because bugs > > are not being fixed. Those are two very different things. Maybe it's just > > too hard > > for volunteers to fix the bugs and make Debian better, and maybe we need to > > pay the volunteers so they are not volunteers anymore and will be motivated > > to actually fix the Debian software. The fact that Debian is created by > > volunteers > > is probably one of the really big disadvantages of Debian software. > > > I think there's a piece missing hugely in *your* equation. > The package maintainer are the LAST line of resort when there's a bug to > fix. Sure you can report them thru BTS but they'll transmit those > upstream to the original software developer. Not in my experience. Most upstream projects say users should report bugs to the distro first and let the distro's maintainers decide what to do. The bugs I see that the Debian maintainer *should* forward to the upstream project usually fail to do that. Of two cases of bugs affecting my machine this past couple of years, one I reported the bug to Debian, Debian's maintainer ignored it, I found the fix after a long bisecting process and the fix was in the upstream part of the code. So I tagged the bug with patch and upstream and waited for the maintainer to forward the bug. The maintainer again ignored it so I had the opportunity to make a contribution to an upstream project and I submitted the patch to the upstream project myself and when it was committed upstream I tagged the bug fixed upstream on BTS and now the bug is closed. That is a happy ending to a bug report. The other one this year both Debian and the upstream project, the Linux kernel, are ignoring the bug and that is the one I described in a post earlier today to this list when I also asked the community a question about systemd, udev, and the coldplug all devices stage of boot where the bug happens. This bug is still not a happy ending, at least for those who want the bug fixed. I am not the one who reported it. I would not be surprised if the one who reported it gave up on it and switched to Fedora or another distro that has fixed the bug in their distro. It is the kind of bug that can be fixed in *either* the Linux kernel upstream code or in the systemd/udev configuration by the distro. But Debian maintainers are just volunteers so they cannot fix it. At least that is what everyone here is telling me. > > What would happened if every bug was fixed by the Debian maintainer ? > We'd end up having two different source code because at every bug fix > there would be a different tree of source code being built. Most users are not able to determine when they report a bug if it is in the upstream or Debian part. I learned how to find where the bug is because no one else in the free software world would do it. You advocate for a world where every user can fix their own bugs and the maintainers can complain they can't fix bugs because they are just volunteers. That doesn't make sense to me. The BTS is useful because users do post workarounds for the bugs that the maintainers don't fix, but users are mistaken if they think when they report a bug the maintainer will see to it that it will get fixed. I also think the bot that says the maintainer will respond to you in due course sometimes lies because in some cases the maintainer never responds. Best regards, Chuck
Re: Paying Debian contributors (Was Re: Advantages/Disadvantages of Open Source Software)
On 9/15/2022 11:46 AM, Andy Smith wrote: > Hello, > > On Wed, Sep 14, 2022 at 10:04:48PM -0400, Chuck Zmudzinski wrote: > > I am not against giving maintainers like Steve just compensation for the > > work they do fixing bugs, and by compensation I mean money. > > It's a very tricky subject to propose to start paying (some?) people > in what was always a volunteer project, to do the same work that > others do voluntarily. It has been proposed before, and it did not > go down well. Search for "dunc tank debian" to read about that. > > More recently (since 2014), the Debian LTS effort started paying > people to upload fixed Debian packages past the end of the normal > release lifetime. This is organised by private company Freexian who > accept sponsorship funds and pay developers to do this work for > Debian, not out of Debian's own funds. > > https://www.freexian.com/services/debian-lts.html > https://wiki.debian.org/LTS > https://wiki.debian.org/LTS/FAQ > > They do LTS, ELTS and some other limited scope efforts. > > If you do use Debian LTS maybe you could consider contributing to > this? Though I would point out: > > - It's not going to give you the right to tell people what to work > on, how to do it, govern their timescales etc. Sponsors are paying > for a certain amount of developer time per month, but Freexian and > those developers decide what to work on and how to do it. > > - At the moment the minimum contribution is €255/year. > > It could also be interesting to explore individual packaging teams > within Debian having Patreon and/or ko-fi accounts or similar. > > Broadly though, none of these small scale funding ideas are ever > going to give you the kind of service you apparently seem to want: > to be able to force the developers to work on what you want them to > work on, in the way you want them to work on it. I can only ever see > that happening in situations where you pay much much more for a > bespoke solution. So I have to pay someone lots of money to fix a problem I already know how to fix? I don't think you really understand my use case very well. Cheers
systemd: udev coldplug all devices question
Hello, There are some devices that when present will cause the "coldplug all devices" stage at boot to fail. On a normally installed system only an error is reported in the journal and logs during boot but the system boots normally and the device also functions normally. But on debian installer media such as netinst or the Debian live installer images, this failure causes a crash and prevents users with such devices from being able to run the debian installer from those installer media. This was reported as a bug over a year and a half ago on BTS, and the bug is currently assigned to linux, that is, the Debian Linux Kernel Team. The problem has also been documented on the Debian installation reports pseudo package. One of the Debian kernel developers suggested a solution of increasing the uevent buffer in the kernel from 2k to 4k, and tests showed that the patch of increasing the buffer in the kernel solved the coldplug all devices problem. That bug of too small a buffer size is in the upstream part of the Linux kernel, so the bug should probably be forwarded to the Linux kernel, and the person who reported the bug (not me) did report the bug to the Linux kernel, as well as to the Debian BTS. But neither Debian nor the Linux kernel has acted on the bug report to try to fix it, except for the suggestion that a Debian kernel developer made to increase the uevent buffer size in the kernel over a year ago and another suggestion from another Debian maintainer or developer who gave me advice on how to document the problem in the installer so the problem could be included on the debian installer errata page, which is why I made the installation report. But the debian installer errata page also was never updated even though I made that installation report over six months ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005308 https://www.debian.org/releases/bullseye/debian-installer/#errata I also tested a current Fedora Workstation 36 installation in the same computing environment, which is a virtual environment, and it exhibited some of the same symptoms that are fixed by the increase of the uevent buffer in the kernel, but on Fedora at the "coldplug all devices" stage during boot, the device that was creating data too big for the uevent buffer in the kernel on both Fedora and Debian did not cause an error message to be printed to the journal and boot logs on Fedora and also on Fedora the live and netinst images do not crash, but on Debian these negative things do happen. Finally, another workaround to make the Debian live image or the Debian netinst image bootable with the problematic device was to edit the udev startup script on the installer image (I think it was in the initrd) to keep it from causing the catastrophic crash when the "coldplug all devices" command is executed, which is actually done, IIUC, by the udevadm executable file. So my question is about udevadm which I think is the command that is executed during boot to coldplug all devices: Is there a way to write the udev rules configuration files so that a particular kind of device that perhaps is not really what I would call "udev-aware" could be excluded from the set of devices that are coldplugged at boot? I am only asking here in case someone knows the answer and is willing to tell me, but if no one here can answer my question I will probably be able to figure it out by examining the differences between the Fedora and Debian udev rules for the various kinds of devices. I suspect that Fedora wrote its udev rules so such devices that are not really the kind of devices that need to be udev-aware and that cause problems or error messages are excluded from the "coldplug all devices" stage of boot. For reference, I am talking about Bug #983357 which is the primary bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357 Thanks in advance for any tips from the udev experts. Kind regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/14/2022 11:01 PM, Maude Summerside wrote: > > On 2022-09-14 21:45, Michael Stone wrote: > > On Wed, Sep 14, 2022 at 11:16:00PM +0100, Steve McIntyre wrote: > >> I'll be brutally honest: being accused of "possibly malicious" > >> unwilligness is *not* a great way to convince overstretched volunteers > >> to spend their time on issues. > > > > Especially when it's an ongoing pattern of discourse. > > > > I think there's many barrier that discourage people from wanting to > contribute to many project. I feel some developer use the community as > unpaid beta tester but don't go further into accepting contribution. > > For sure, having managed some project, I have to say that it's hard to > accept contribution that will add new functions to as software when > these come from a unknown contributor. Not because of being scared of > malicious intent (unless the person is really paranoid but that's > another story). Simply because adding a new function means having to > support it's ongoing development and there's no guarantee that the > contributor will do so. Same goes on for code contributed that needs > refactoring, that are badly documented, etc. But all this need some good > social behavior from the project owner/manager. As a user of the Debian software and a user of the BTS, I am discouraged not because new contributions or functions are being rejected, but because bugs are not being fixed. Those are two very different things. Maybe it's just too hard for volunteers to fix the bugs and make Debian better, and maybe we need to pay the volunteers so they are not volunteers anymore and will be motivated to actually fix the Debian software. The fact that Debian is created by volunteers is probably one of the really big disadvantages of Debian software. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/14/22 6:16 PM, Steve McIntyre wrote: > Stefan wrote: > In article you > write: > >> the interest of the user. These "volunteers" obviously have other, > >> possibly malicious, interests if they prove themselves unwilling to > >> apply fixes to bugs that are reported to them. > > > >I think there's a confusion here: these volunteers will also have > >"other, possibly malicious, interests" even if they are willing/eager > >to apply fixes to bugs that are reported to them. > > > >Same goes for people you pay, so it's not specific to volunteers. > >And of course it's also not specific to a particular kind of license. > > Thanks Stefan, it's great to see that some people understand the > issues. > > I'll be brutally honest: being accused of "possibly malicious" > unwilligness is *not* a great way to convince overstretched volunteers > to spend their time on issues. > Thank you Steve, for the work you do as maintaining the grub software packages on Debian. I am not against giving maintainers like Steve just compensation for the work they do fixing bugs, and by compensation I mean money. Why not require the user to pay a small fee when reporting a bug which can be used to provide just compensation for the services the maintainers provide to the community when the maintainer fixes bugs? I would be willing to pay a reasonably small fee that would go to the maintainers who worked on the bug and successfully fixed it. I'll be brutally honest: Being accused of being a troll is *not* a great way to convince Debian users who want to contribute to and help Debian to spend their free time helping maintainers fix the bugs reported to the BTS. I also suspect many users agree with me, but are afraid to say so for fear of being accused of being a troll. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/14/2022 9:06 AM, The Wanderer wrote: > On 2022-09-14 at 08:51, Chuck Zmudzinski wrote: > > > On 9/14/2022 1:03 AM, to...@tuxteam.de wrote: > > > >> On Tue, Sep 13, 2022 at 03:41:11PM -0400, Chuck Zmudzinski wrote: > >> > >> [...] > >> > >>> Actually, someone already has shown us how to do it better. His name is > >>> Linus Torvalds [...] > >> > >> I don't know what your aim is. > >> > >> I have the impression that it's just arguing for arguing's sake [1]. > >> > >> [1] in the classical sense of "trolling", as per Wikipedia: > >> "In Internet slang, a troll is a person who posts inflammatory, > >> insincere, digressive,[1] extraneous, or off-topic messages in > >> an online community [...], with the intent of provoking readers > >> into displaying emotional responses,[2] or manipulating others' > >> perception. > >> https://en.wikipedia.org/wiki/Trolling > > > > So you are accusing me of being a troll. Well, it takes one to know one. > > No, it very much does not. > > > Congratulations! I am starting my own list of trolls on debian-user and > > you are the first member of that list. > > Given the long, long history of helping people that Tomas has on this > mailing list, I think that if you want to convince anyone other than > yourself that Tomas is a troll, you're going to have a *very* heavy lift > (or a whole lot of lying) ahead of you. > > (Mind, by my personal definition - which is a bit different from the > above, though probably still largely compatible - I'm not entirely > convinced that you're a troll either. But you're *definitely* behaving > in such a way that I do not blame others for reaching that conclusion.) I admit that I behaved like a troll when i tried to enter into a conversation with Tomas. I do know he helps many people on this list, that is something good he does. But on this thread, he also behaved like a troll and caused me to also behave like a troll. That is a fact, if anyone wants to take the time to look at what he said, the things he omitted in his replies, etc. I especially noted his response to my introduction of the idea in this thread that open source projects like Debian consider themselves communities, and I wanted to emphasize that those who volunteer to help out with Debian or other free software communities should not serve their own interests but the interests of the community. After I made those points, that is when Tomas started his ad hominum attacks against me and turned the conversation away from what it means for Debian to be a community and changed it into an ad hominum attack against me. It causes me to think there are some aspects of the idea of Debian as a community that are offensive to him. From what he actually did in this thread, I am inclined to think his idea of Debian as a community is that it is a community of developers only, and not of users. Maybe he is right about that. Maybe Debian *is only* a community of the one thousand or so Debian developers with voting rights, and the rest of us are trolls if we dare to express our opinions as mere Debian users on the debian-user list or on any other Debian hosted forum. So I am going to be very careful about trying to have an objective conversation with Tomas, given what I actually saw him do in this thread, and given the mistake I made by letting him bait me into appearing to be a troll. I will be careful to not let that happen again. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 7:11 PM, Thiemo Kellner wrote: > Am 13.09.22 um 23:55 schrieb Chuck Zmudzinski: > > > > > I am fairly sure I was a victim of > > the breach of Yahoo that affected hundreds of millions of its users. > I am sorry for you. I do not know this case, so I cannot tell whether > OSS or CSS components of their service were breached, or even a social > engineering case. There is information about the Yahoo data breach on the Internet, including the $117 million class action case on behalf of 194 million class members: https://www.cnbc.com/2020/02/06/what-to-do-if-you-got-email-from-yahoo-about-a-data-breach-settlement.html I don't know if there is enough information available in the public domain to determine to what extent free/oss software might have contributed to that data breach. I do remember Yahoo admitted the number of affected accounts was around 500 million. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/14/2022 1:03 AM, to...@tuxteam.de wrote: > On Tue, Sep 13, 2022 at 03:41:11PM -0400, Chuck Zmudzinski wrote: > > [...] > > > Actually, someone already has shown us how to do it better. His name is > > Linus Torvalds [...] > > I don't know what your aim is. > > I have the impression that it's just arguing for arguing's sake [1]. > > [1] in the classical sense of "trolling", as per Wikipedia: > "In Internet slang, a troll is a person who posts inflammatory, > insincere, digressive,[1] extraneous, or off-topic messages in > an online community [...], with the intent of provoking readers > into displaying emotional responses,[2] or manipulating others' > perception. > https://en.wikipedia.org/wiki/Trolling > So you are accusing me of being a troll. Well, it takes one to know one. Congratulations! I am starting my own list of trolls on debian-user and you are the first member of that list. Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/14/2022 7:08 AM, debian-u...@howorth.org.uk wrote: > > On 9/13/2022 3:59 PM, err...@free.fr wrote: > > > Please STOP! > > > > > > you are annoying, and if you want improve free softwares, is not > > > like this. you will better contribute with your code or with your > > > translations than by writing to this mailing-list > > I agree with the sentiments of annoyance and that this thread should > stop now, please. Not everyone agrees, because some have still been making comments here that in my opinion and theirs are constructive and not just trolling. > > > The problem is, with all due respect, that I do have my code > > improvements for free software, but some free software people do not > > want to accept my contributions but instead want to allow the free > > software to continue to have the bugs, and they will not explain > > themselves either. Why should I waste my time contributing to > > software projects who do not want my contributions? Treating people > > who want to contribute this way is not the way to gain more advocates > > for free software! > > But again you have been asked before to be specific about your > objections, so a link to your proposed code improvements and whatever > conversation there was when you submitted them would go some way to > justifying the space and time you have already wasted on this list. > > > > I want you kicked from this list. > > > > Well, if you get me kicked off, I will be kicked off. But that is not > > the way to build a community of people trying to make good software. > > That is all I am advocating for, and I am really surprised to be > > treated this way on this list for advocating for improved software in > > Debian. I guess the trolls on here do not really want to increase the > > number of people working on improving Debian. But without more > > people, Debian cannot possibly provide quality support for 59,000 > > free software packages. That is just a fact, even it no one here > > wants to acknowledge it. > > I haven't seen much evidence of trolls here, apart from yourself. I did make the mistake of feeding a couple of trolls, from now on I will ignore them. They baited me into appearing as a troll by refusing to acknowledge a simple truth and forcing me to say the same obvious truth over and over again, and I understand why some people might be annoyed by that. Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 7:11 PM, Thiemo Kellner wrote: > Am 13.09.22 um 23:55 schrieb Chuck Zmudzinski: > > On 9/13/2022 4:14 PM, Thiemo Kellner wrote: > > I think Megha is emphasizing, and possibly over-emphasizing, the fact > > that the persons > > who actually commit the code in free software projects can operate with > > little or > > no oversight when they are just volunteers not really accountable to anyone. > And I very much think she is wrong there. Being software developer > myself, unfortunately closed source mainly, I can tell that oversight is > not related to the licensing model or the pay of the developer. I would > go to the length to say that volunteers take, in general, a bigger pride > in the quality of their work, because they are not payed for it. The few > quite fruitless attempts in writing OSS, I took, failed sometimes > because I intend to create the perfect solution and thus not > progressing, whereas in the work for money I am often forced to > implement a working solution I can tell from the start, it will not be > easily maintainable or extendable. > > to think the situation might be better if either 1) open source projects > > exercised more > > oversight than they currently do over the persons who actually write the > > code and > > release the software > As I already told. In over 25 years of experience, I do not have > complaints about the oversight taken by OSS projects, where as I > regularly can complain about closed source payed for software. In the > past two weeks I was hunting down a problem we had with IBM DataStage. > One of the parallel subprocess terminated unexpectedly and all the > message DataStage cared to give was that the subprocess received a > SIGINT. We hope to have work around, because we could not find the > source. To me, one of the worst things one can do as developer not to > have proper error reporting - unless you know, you will not get bothered > when the shit starts to hit the fan. > > , or 2) free/oss software never became ubiquitous. We just cannot > > know without being able to do a time machine experiment and see how the > > software > > world would have developed if free/oss software had not become as > > ubiquitous as it is > > today. > I cannot agree with you at all on this point. Omnipresence of OSS does > not mean there are more error in the code. It just means there are more > users to detect problems, thus more possiblities for the bugs to get > fixed. Sure, if OSS developers are overloaded the will not get to fix > all the problems, just as developers on CSS (closed source software). > Much more, because the sales man can sell better new shiny features even > if useless, than stable code. The buyer expects that flaws get fixed for > free, maybe rightly so, thus the CSS company will fix as few bugs it can > get away with (exageration). > > If there was not a serious problem of malware, identity theft, ransomware, > > etc., > > I would be more inclined to question what Megha Verma wrote, but based on > > what > > I see in how free/oss projects are governed, I am not surprised that a > > world that relies > > on so much free/oss software also suffers from so much malware, ransomware, > > identity > > theft, etc. > Again, my experience with OSS is not this one. And I very much think, > that malware, ransomware usually is software on its own not built-in any > software. Maybe exploiting a backdoor a company put in their products > for ease of maintenance or just by negligence. Identity theft sounds > like social engineering or man in the middle attack. The latter not > necessarily being a problem of OSS. > > Just because *you* have not experienced malware in the software you use > > does not mean that there are no cases where free/oss software is being > > deployed > > elsewhere in a stealthy way for malicious purposes. > > I did not state that OSS was free of flaws and bugs. I am make a point > to state that in my experience there are fewer bugs therein than in CSS. > > > I am fairly sure I was a victim of > > the breach of Yahoo that affected hundreds of millions of its users. > I am sorry for you. I do not know this case, so I cannot tell whether > OSS or CSS components of their service were breached, or even a social > engineering case. > > > > I know people will reply and say it is much worse with proprietary > > software. But we > > really cannot know for sure, because free/oss is so ubiquitous now it is > > hard to > > separate free/oss software from proprietary software. > > I certainly can tell my experience comparing OSS to CSS. And
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 6:47 PM, Stefan Monnier wrote: > > If free/oss projects like Debian want to provide software with those > > positive characteristics to their users, those projects must have in > > place some level of oversight over what the persons who actually write > > the software actually do, or don't do in the case of failing to fix > > bugs that could easily be fixed, so that the goals of quality, useful, > > safe, and secure software are reached. > > That's why I like Free Software: all of this is done out in the open, > making oversight particularly easy. > > For proprietary code you generally simply can't do that at all because > it's all kept secret. > > > Stefan > We really agree on this point, thanks. Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 4:38 PM, Stefan Monnier wrote: > > The users. They stop using software or any product that does not work > > well or is more trouble than it is worth. Then the entity, whether > > a free/oss or proprietary provider ends up shutting down > > the enterprise. > > But, being Free Software, any remaining user can keep using it, > improving it, checking if it contains any back doors, hire someone else > to do it, etc... > > >> You do realize that nobody enforces that on proprietary software > >> either, right? > > The users do, in the marketplace - and what is not used by enough > > users eventually disappears. > > That's right. And then you're typically completely screwed even if it > happened to work well for you. > > The company will also blissfully ignore your requests if you're part of > too-small a slice of their users. Ever tried to get an `armhf` binary for > a proprietary GNU/Linux software? > > > I think it is true that the "best" software development model depends > > less on free/oss vs. proprietary and more on the wisdom, foresight, > > integrity, and technical expertise of those doing the work and making > > the important decisions. > > I don't care which is better. I just prefer not to depend on the > goodwill of a company (most of which I know act against my interest; > probably inevitably because they are beholden to their shareholders). Of course you know many of those companies that you know act against your interests have employees who "volunteer" to contribute to free/oss software projects, so in practice the free/oss software is not free from this problem, but a truly open project can make it possible to find out which volunteers are not acting in the true interests of those who advocate for the benefits of free/oss software, and this is not possible in secretive, proprietary organizations. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 4:31 PM, Stefan Monnier wrote: > > the interest of the user. These "volunteers" obviously have other, > > possibly malicious, interests if they prove themselves unwilling to > > apply fixes to bugs that are reported to them. > > I think there's a confusion here: these volunteers will also have > "other, possibly malicious, interests" even if they are willing/eager > to apply fixes to bugs that are reported to them. > > Same goes for people you pay, so it's not specific to volunteers. > And of course it's also not specific to a particular kind of license. > > > Stefan > So I presume you agree that no matter the kind of license, development model, etc., it is in the interest of the users of software for there to be oversight of what the persons who actually write the code and release the software to the public actually do to deter them from doing anything malicious, and if they do not act in the interest of the users, then they are undermining the purpose of any software project that claims to provide quality software that is secure, useful, and safe to use. If free/oss projects like Debian want to provide software with those positive characteristics to their users, those projects must have in place some level of oversight over what the persons who actually write the software actually do, or don't do in the case of failing to fix bugs that could easily be fixed, so that the goals of quality, useful, safe, and secure software are reached. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 4:14 PM, Thiemo Kellner wrote: > Am 12.09.22 um 19:47 schrieb Chuck Zmudzinski: > > "Open Source Software is accessible to all means it can be used and > > misused. > > And, that’s where it turns unconstructive for us. With OSS, we can expect > > harm, > > virus transfer, identity burglary, and many other malicious practices to > > hurt the > > process." [1] > > ... > > > > [1] > > https://medium.com/quick-code/advantages-disadvantages-of-open-source-software-explained-2fd35acd413 > > Hi Chuck > > ... > > I do not quite get the meaning of "Open Source Software is accessible to > all means it can be used and misused." by Megha Verma. Assuming that it > is by its nature possible to "inject" malicious code then yes and no. > Yes, it theoretically is possible as anyone can get and change the code, > but no, if the project is fairly well maintained, i.e. no commits to the > main branch of the code repository without any review. Personally, I > have been using OSS for more than 25 years and never had the suspicion > any of the OSS I used was acting malicious. I think Megha is emphasizing, and possibly over-emphasizing, the fact that the persons who actually commit the code in free software projects can operate with little or no oversight when they are just volunteers not really accountable to anyone. Also, we do not really know what the malware/ransomware situation would be like today around the world if free/oss software were not as ubiquitous as it is today in web servers, phone operating systems like android, etc. It clearly is not a good situation now regarding malware and ransomware around the world, and it is not unreasonable to think the situation might be better if either 1) open source projects exercised more oversight than they currently do over the persons who actually write the code and release the software, or 2) free/oss software never became ubiquitous. We just cannot know without being able to do a time machine experiment and see how the software world would have developed if free/oss software had not become as ubiquitous as it is today. If there was not a serious problem of malware, identity theft, ransomware, etc., I would be more inclined to question what Megha Verma wrote, but based on what I see in how free/oss projects are governed, I am not surprised that a world that relies on so much free/oss software also suffers from so much malware, ransomware, identity theft, etc. Just because *you* have not experienced malware in the software you use does not mean that there are no cases where free/oss software is being deployed elsewhere in a stealthy way for malicious purposes. I am fairly sure I was a victim of the breach of Yahoo that affected hundreds of millions of its users. A word to the wise: be vigilant about the software you use and take note of any red flags. I know people will reply and say it is much worse with proprietary software. But we really cannot know for sure, because free/oss is so ubiquitous now it is hard to separate free/oss software from proprietary software. For example, most web browsers are based on chromium, a free oss project that comes in large part from Google, but some of the most-used browsers in the world based on chromium are proprietary, such as chrome and edge. I recommend everyone be very aware of the risks of using any software, whether it be proprietary software or free/oss software in today's world of so much malware. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 3:59 PM, err...@free.fr wrote: > Please STOP! > > you are annoying, and if you want improve free softwares, is not like this. > you will better contribute with your code or with your translations than by > writing to this mailing-list The problem is, with all due respect, that I do have my code improvements for free software, but some free software people do not want to accept my contributions but instead want to allow the free software to continue to have the bugs, and they will not explain themselves either. Why should I waste my time contributing to software projects who do not want my contributions? Treating people who want to contribute this way is not the way to gain more advocates for free software! > > I want you kicked from this list. Well, if you get me kicked off, I will be kicked off. But that is not the way to build a community of people trying to make good software. That is all I am advocating for, and I am really surprised to be treated this way on this list for advocating for improved software in Debian. I guess the trolls on here do not really want to increase the number of people working on improving Debian. But without more people, Debian cannot possibly provide quality support for 59,000 free software packages. That is just a fact, even it no one here wants to acknowledge it. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 2:33 PM, Michael Stone wrote: > On Tue, Sep 13, 2022 at 02:14:38PM -0400, Chuck Zmudzinski wrote: > >So do you, obviously. Someone said something that raised that question in my > >mind, > >but you deleted that part from this message, which proves you are the one > >who has > >an ax to grind by not answering the question that has been raised by the > >comments > >you and another person has been making. > > What question? You identified "rhetorical questions" that you wanted me to stop. > I saw no question. Either talk about specifics or it's > nothing but empty FUD. > > >> Either get to the point and discuss > >> what's bothering you directly or stop with the pointless rhetorical > >> questions. > >> > > > >It bothers me that there are supposed advocates of free/oss software like > >Debian > >who think that it is good for free/oss software if the persons who volunteer > >to develop and maintain free software like Debian can ignore bugs reported > >to them > >and refuse to fix them. > > Here's the thing: it's open source. If you think it's not being done > right THEN YOU DO IT DIFFERENTLY. If you don't like how some software is > being maintained, fork it and show everyone how it can be done better. Actually, someone already has shown us how to do it better. His name is Linus Torvalds. Debian and other oss projects should see and understand what he does that makes the Linux kernel a truly useful software project. Debian is successful because of the Linux kernel, not the other way around. Since you bring up forks, I have an opinion about that. Everyone have their own fork is not a sustainable model for free/oss software, IMHO. If everyone needs to have their own fork, that is because of the failure of the way free/oss projects are governed. Again this is just my opinion, but I think it is valid. There is a place for some forks when the goal of the project has a particular focus, but for a project like Debian, which currently claims to support 59000 free software packages in the stable distribution, the focus is on general purpose computing and, IMHO, it is a failure for Debian and free/oss software when a fork such as Devuan happens. The Devuan fork proved how ridiculous it is for Debian to claim to be able to support 59000 software packages in its stable distribution, which is currently what the "Reasons to use Debian" page on debian.org claims. I think that if Debian really wants to provide *high quality* support for each and every one of the 59000 software packages in its repositories, it should look at the Devuan fork and try to understand what it could have done to prevent it from happening. All those people working on Devuan could still be working on Debian. I don't understand why it was good for that fork to happen. Just my opinion, FWIW. > > It's unreasonable to just sit on the sidelines and make vague > accusations. The ax you want to grind seems to involve one specific > issue. The issue is the survival of free/oss software - it will not survive if the idea that those who develop and maintain free/oss software don't have to respond to the bugs that are reported to them prevails. No one will use it if the people who create it are free to let the problems that inevitably arise go without fixing them. > Tell us what it is, then everyone can decide for themselves > whether you have a point, whether it can/should be addressed, or whether > you're just mad that you can't make someone else do what you want. I think I have clarified what the issue is sufficiently. I am not mad that I cannot make someone else do what I want. I would just be sad if free/oss software dies out because it was taken over by people who refused to acknowledge the simple idea that it is bad for free/oss software if those who develop and maintain the software are free to not fix the bugs that users report to them. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 2:02 PM, Michael Stone wrote: > On Tue, Sep 13, 2022 at 12:42:12PM -0400, Chuck Zmudzinski wrote: > >Software projects today, IIUC, are communities. The "volunteers" should do > >what the community > >wants, not necessarily what you or I want. Do you think the free/oss > >software community wants > >volunteers who ignore bugs or refuse to fix bugs in free/oss software? If > >they do ignore a > >bug or refuse to fix a bug with a known fix, don't they owe an explanation > >to the community? > >If not, why not? > > You seem to have an ax to grind. So do you, obviously. Someone said something that raised that question in my mind, but you deleted that part from this message, which proves you are the one who has an ax to grind by not answering the question that has been raised by the comments you and another person has been making. > Either get to the point and discuss > what's bothering you directly or stop with the pointless rhetorical > questions. > It bothers me that there are supposed advocates of free/oss software like Debian who think that it is good for free/oss software if the persons who volunteer to develop and maintain free software like Debian can ignore bugs reported to them and refuse to fix them. If you think that is good for free/oss software, I disagree with you. Fortunately, you are just one person, and I doubt the Debian community or any other free software community wants the persons who develop and maintain the software to ignore and/or refuse to fix the bugs reported to them. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 12:36 PM, to...@tuxteam.de wrote: > On Tue, Sep 13, 2022 at 12:25:40PM -0400, Chuck Zmudzinski wrote: > > [...] > > > I agree with that. But the price-performance ratio could be even better if > > the "volunteers" > > in free/oss software projects were not free to ignore bugs reported to them. > > Hm. I doubt that. Perhaps they will do more what *you* want, Software projects today, IIUC, are communities. The "volunteers" should do what the community wants, not necessarily what you or I want. Do you think the free/oss software community wants volunteers who ignore bugs or refuse to fix bugs in free/oss software? If they do ignore a bug or refuse to fix a bug with a known fix, don't they owe an explanation to the community? If not, why not?
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 11:53 AM, Michael Stone wrote: > On Tue, Sep 13, 2022 at 11:27:43AM -0400, Chuck Zmudzinski wrote: > >On 9/13/2022 12:36 AM, to...@tuxteam.de wrote: > >> On Mon, Sep 12, 2022 at 03:32:27PM -0400, Michael Stone wrote: > >> > >> > [...] "I can't get personalized/dedicated support with enforceable > >> > SLAs for free" > > > >If the requirement that maintainers and developers of free/oss software must > >actually > >fix the bugs reported to them is not enforced, then free/oss software *is* > >vulnerable to > >all kinds of malicious activity by the "volunteers" who create the free/oss > >software. > > Enforced by whom? How? The users. They stop using software or any product that does not work well or is more trouble than it is worth. Then the entity, whether a free/oss or proprietary provider ends up shutting down the enterprise. > You do realize that nobody enforces that on > proprietary software either, right? The users do, in the marketplace - and what is not used by enough users eventually disappears. > THIS IS NOT A CHARACTERISTIC THAT > DISTINGUISHES OPEN SOURCE AND CLOSED SOURCE SOFTWARE. Given that, > continuing this discussion seems silly. (Especially since it appears > that you'll simply to repeat your original assertion, mistaken though it > is, without even trying to address to the points that others have made.) > I think it is true that the "best" software development model depends less on free/oss vs. proprietary and more on the wisdom, foresight, integrity, and technical expertise of those doing the work and making the important decisions. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 11:44 AM, to...@tuxteam.de wrote: > On Tue, Sep 13, 2022 at 11:27:43AM -0400, Chuck Zmudzinski wrote: > > On 9/13/2022 12:36 AM, to...@tuxteam.de wrote: > > > On Mon, Sep 12, 2022 at 03:32:27PM -0400, Michael Stone wrote: > > > > > > > [...] "I can't get personalized/dedicated support with enforceable > > > > SLAs for free" > > > > If the requirement that maintainers and developers of free/oss software > > must actually > > fix the bugs reported to them is not enforced, then free/oss software *is* > > vulnerable to > > all kinds of malicious activity by the "volunteers" who create the free/oss > > software. > > > > > > > > Had I a printer, I'd print out this, frame it and hang it on the > > > wall. This makes the point very nicely :-) > > > > > > Cheers > > > > Yes, it is true, no one should use Debian or any software maintained by > > totally > > unaccountable "volunteers" for any mission-critical purpose without also > > hiring > > someone with the time and expertise to do what is necessary to make such > > software > > secure and bug-free for the intended purpose of the software. That is, users > > must *not trust* the volunteers who maintain and develop Debian software to > > act in > > the interest of the user [...] > > But how is that different from commercial software? Not that much different. I like the fact that we have free/oss software now so we can see which "volunteers" who sometimes work for big corporations choose to ignore bugs reported to them. I won't trust those "volunteers" nor will I trust the companies they work for, nor will I trust the software and hardware those companies release into the marketplace. I also think it is better for free/oss projects to enforce some minimum level of effort on the "volunteers" who maintain and develop the software to reduce the chances that the "volunteers" can get away with abusing their position as "volunteers" who have the power to upload official software to the free/oss projects' download servers. > The commercial entity > is bound to the shareholders and to the paying customers -- based on how > much they pay for. If you, as a customer, are shelling out a significant > amount of money, you can as well pay a dedicated person to keep your > free software in shape. Probably the price-performance ratio will be > better. I agree with that. But the price-performance ratio could be even better if the "volunteers" in free/oss software projects were not free to ignore bugs reported to them. Cheers
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/13/2022 12:36 AM, to...@tuxteam.de wrote: > On Mon, Sep 12, 2022 at 03:32:27PM -0400, Michael Stone wrote: > > > [...] "I can't get personalized/dedicated support with enforceable > > SLAs for free" If the requirement that maintainers and developers of free/oss software must actually fix the bugs reported to them is not enforced, then free/oss software *is* vulnerable to all kinds of malicious activity by the "volunteers" who create the free/oss software. > > Had I a printer, I'd print out this, frame it and hang it on the > wall. This makes the point very nicely :-) > > Cheers Yes, it is true, no one should use Debian or any software maintained by totally unaccountable "volunteers" for any mission-critical purpose without also hiring someone with the time and expertise to do what is necessary to make such software secure and bug-free for the intended purpose of the software. That is, users must *not trust* the volunteers who maintain and develop Debian software to act in the interest of the user. These "volunteers" obviously have other, possibly malicious, interests if they prove themselves unwilling to apply fixes to bugs that are reported to them. Thanks for clarifying that fact. Best regards
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/12/22 3:32 PM, Michael Stone wrote: > On Mon, Sep 12, 2022 at 01:47:49PM -0400, Chuck Zmudzinski wrote: > >Well, I suppose so, but I am pleased that a grub maintainer is now on the > >case. Still, > >there is another Debian bug that affects me that continues to be ignored, so > >I admit > >I have an attitude about that. I accept that what is of grave or important > >severity to > >me is not necessarily of grave or critical severity to the official Debian > >maintainers > >and developers. I wish to merely point out that what is often said about the > >advantages > >and disadvantages of free, open-source software that is maintained by > >volunteers is > >true: > > No, it's a misguided conclusion that isn't supported by facts. I can > think of any number of bugs in closed source software that aren't fixed. > The only real difference is this: with open source software you might > actually be told "I'm not going to prioritize this because I'm a > volunteer and prefer to do something else", while with propietary > software the discussion that concludes "this customer isn't important > enough to require a change in the priority of the request" isn't going > to be public and all you'll ever be told is that the request is being > reviewed or somesuch. > > There is an exception that proves the rule, however: if you're a large > enough customer, paying enough money, you may well get a team of people > dedicated to implementing whatever you ask for. But here's the > thing--you can get the same level of service for open source software, > if you're willing to pay for it. (Not directly from debian, but there > are consultants/etc that will provide such services.) Your complaint > really boils down to "I can't get personalized/dedicated support with > enforceable SLAs for free", which is just as true for proprietary > software as it is for open source software. > I actually agree free/oss is better - if I was a big paying customer (I am not), I would pay for a free/oss solution instead of a proprietary solution because the entire development of the solution would be in the open which would make it more difficult for the persons implementing the solution to do anything malicious behind closed doors. Still, I think it is obvious that the success of free/oss projects depends very much on whether or not the persons who volunteer as developers and maintainers actually respond to and fix bugs. Also, if the persons who volunteer as developers and maintainers can ignore bug reports without any consequences from the community, then the possibility for free/oss software to fully realize the advantages of the free/oss software development model over the proprietary model is undermined. Best regards, Chuck
Re: Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/12/2022 1:58 PM, The Wanderer wrote: > On 2022-09-12 at 13:47, Chuck Zmudzinski wrote: > > > On 9/12/2022 12:14 PM, David Wright wrote: > > > >> On Mon 12 Sep 2022 at 11:13:52 (-0400), Chuck Zmudzinski wrote: > > >>> The grub maintainers do not have the time or interest to fix it. > >>> Perhaps the Xen users could try to convince the Xen maintainers > >>> to do an nmu to fix it if the grub maintainers continue to ignore > >>> the bug, but I don't know if that breaks the etiquette that > >>> governs such things in the world of Debian developers - I am just > >>> a Debian user. > >> > >> There seems to be some attitude here. > > > > Well, I suppose so, but I am pleased that a grub maintainer is now on > > the case. Still, there is another Debian bug that affects me that > > continues to be ignored, so I admit I have an attitude about that. I > > accept that what is of grave or important severity to me is not > > necessarily of grave or critical severity to the official Debian > > maintainers and developers. I wish to merely point out that what is > > often said about the advantages and disadvantages of free, > > open-source software that is maintained by volunteers is true: > > > > An advantage is that the user has full access to the source code and > > is free to fix problems if the official releases have unpatched bugs > > but this of course costs time and resources devoted to solving > > problems that are not fixed promptly in the official release. A > > disadvantage is that often the priorities of the developers who > > release free, open source software are not always the same as the > > priorities of any particular user, so there is no guarantee that the > > developers of free, open source software will ever get around to > > fixing a problem that might be causing trouble for some subset of > > users of the software who very often just stop using the free, open > > source software and return to proprietary software that just works > > for them without a big hassle or effort to keep it working well and > > securely. > > I am inclined to dispute one aspect of this characterization. > > That which you cite here as a disadvantage is only a disadvantage > (relative to proprietary software) if the proprietary software does, as > you say, "just work for them". > > It is equally possible (if not more) to find that a given piece of > proprietary software does not meet your needs (because the priorities of > its developers, or at least the people who pay them, do not match your > priorities). > > If that happens, you don't even have the option of falling back to hack > the source and run your own version; you're effectively stuck. As I > understand matters, that is in fact the reason Free Software was > invented in the first place. > > With access to the source and appropriate license guaranteeing you the > right to modify it (et cetera), if the priorities of the developers > don't match yours you do at least have the possibility of going in and > fixing it yourself - whether as a patch to go upstream, or a public > fork, or even just a local fork. With proprietary software, you don't > have that option. > > As such, not only is this not a disadvantage unique to Free Software, > it's a disadvantage that exists even *worse* with proprietary software. > I agree OSS that works well is much better than proprietary software, because it makes a software solution that works well accessible to all the users. The disadvantage is that in practice, OSS does not always work as well and is sometimes more buggy than proprietary software when, for example, the developers and maintainers are unwilling or unable to fix bugs or add features and the users do not have the ability to fix the problems or convince the developers to fix the problems, and it is especially a problem when the only reason the OSS supporters give for not fixing problems is: "we are just volunteers." Really good, secure software is not going to come from volunteers who are never required to at least explain why they fail to fix bugs that have a known fix but remain open for an unreasonably long time due to the lack of attention to the bug by the developers and maintainers. Unfortunately, this does happen in Debian, and as long as defenders of OSS continue to say, "they are just volunteers," there will always be a risk that the "volunteers" will be able to sabotage the real goals of OSS software. In the end, though, OSS is probably best because those who do sabotage OSS software eventually get caught precisely because the process of developing OSS is also open so the malice is eventually discovered by the community and the malicious actors are removed from positions where they can cause harm. Best regards, Chuck
Advantages/Disadvantages of Open Source Software (Was Re: Package grub-xen-host breaks PV domains with 11.5 point release)
On 9/12/2022 12:14 PM, David Wright wrote: > On Mon 12 Sep 2022 at 11:13:52 (-0400), Chuck Zmudzinski wrote: > > On 9/12/2022 12:55 AM, David Wright wrote: > > > > > > I would imagine a fix could follow quite quickly as it only requires > > > rebuilding with a filename added to a list of files not to have > > > their symbols stripped (or reverting the compatibility level change). > > > > The patch to fix the bug with the dh_strip override was identified six days > > ago > > in the bug report by a user, yet AFAICT the grub maintainers have not even > > acknowledged the existence of this bug yet to those who have contributed > > to the bug report on BTS. So I do not expect a fix very soon. > > I don't see why: I see Steve's post from several hours ago. Sorry, I missed that, Steve is a grub maintainer and now he is looking at the bug, and that is a good and encouraging fact. > > > The grub maintainers > > do not have the time or interest to fix it. Perhaps the Xen users could try > > to > > convince the Xen maintainers to do an nmu to fix it if the grub maintainers > > continue to ignore the bug, but I don't know if that breaks the etiquette > > that > > governs such things in the world of Debian developers - I am just a Debian > > user. > > There seems to be some attitude here. Well, I suppose so, but I am pleased that a grub maintainer is now on the case. Still, there is another Debian bug that affects me that continues to be ignored, so I admit I have an attitude about that. I accept that what is of grave or important severity to me is not necessarily of grave or critical severity to the official Debian maintainers and developers. I wish to merely point out that what is often said about the advantages and disadvantages of free, open-source software that is maintained by volunteers is true: An advantage is that the user has full access to the source code and is free to fix problems if the official releases have unpatched bugs but this of course costs time and resources devoted to solving problems that are not fixed promptly in the official release. A disadvantage is that often the priorities of the developers who release free, open source software are not always the same as the priorities of any particular user, so there is no guarantee that the developers of free, open source software will ever get around to fixing a problem that might be causing trouble for some subset of users of the software who very often just stop using the free, open source software and return to proprietary software that just works for them without a big hassle or effort to keep it working well and securely. Megha Verma of medium.com goes so far to say a disadvantage of OSS is that free open source software can be misused for malicious purposes, but it would be hard to prove what she says is true, but her point is that the way open source projects are governed lends itself to possible abuse. This is how she explains it: "Open Source Software is accessible to all means it can be used and misused. And, that’s where it turns unconstructive for us. With OSS, we can expect harm, virus transfer, identity burglary, and many other malicious practices to hurt the process." [1] I would not go so far to say that is happening in Debian, but I have experienced the fact that not every bug that is important to my use case will be fixed quickly in Debian, even if I or other users takes the time to find the fix and share it with the Debian developers. This experience of mine with Debian as a long-time user of Debian *does* raise suspicion in my mind, and I would not be suspicious of malicious intent by Debian developers and maintainers if they were more responsive to some bugs they just ignore for months and even years. I agree my suspicion does not prove malice, but my suspicion is reasonable when there are Debian "volunteers" who do work in corporate environments where the interests of their employer might conflict with the interests of the open source software projects such as Debian that they contribute to. This is simply a risk that users of Debian software, or of any open source software, should be aware of, and users should know how to mitigate this risk of malicious activity within open source software projects like Debian. So it as a fact that if a person is just a user of Debian and not an official developer of Debian, there is no guarantee that the use case of that particular user will receive prompt attention from the official Debian developers. That is true because Debian developers are just volunteers and not liable for any problems the software they release might cause to those who use Debian software. That is a *big disadvantage* of open source software. Best regards, Chuck [1] https://medium.com/quick-code/advantages-disadvantages-of-open-source-software-explained-2fd35acd413
Re: Should a serious bug have made in into bullseye 11.5?
On 9/12/2022 11:36 AM, Tim Woodall wrote: > On Mon, 12 Sep 2022, David Wright wrote: > > > > > AFAICT it had two months in testing without this problem being > > hit and reported. > > > > Unfortunately, g-x-h is probably mostly used on stable or oldstable with > guests running testing. > > I'm not sure if it's possible to run a xen hypervisor in a domu - that > would be an interesting way to run testing. > > Tim. > I think that xen hypervisor running in a domu is called nested virtualization. The Xen project defines support for this as follows [1]: ### x86/Nested PV This means running a Xen hypervisor inside an HVM domain on a Xen system, with support for PV L2 guests only (i.e., hardware virtualization extensions not provided to the guest). Status, x86 Xen HVM: Tech Preview This works, but has performance limitations because the L1 dom0 can only access emulated L1 devices. Xen may also run inside other hypervisors (KVM, Hyper-V, VMWare), but nobody has reported on performance. ### x86/Nested HVM This means providing hardware virtulization support to guest VMs allowing, for instance, a nested Xen to support both PV and HVM guests. It also implies support for other hypervisors, 739 such as KVM, Hyper-V, Bromium, and so on as guests. Status, x86 HVM: Experimental [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=SUPPORT.md;hb=HEAD
Re: Package grub-xen-host breaks PV domains with 11.5 point release
On 9/12/2022 12:55 AM, David Wright wrote: > On Mon 12 Sep 2022 at 01:15:47 (+0200), Tom Lew wrote: > > This is my first post, bear with me.. > > > > Package "grub-xen-host" shipped with point release 11.5 broke all PV > > domains on my Xen server, after "apt upgrade" from 11.4. > > > > I found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 > > exactly mirroring my situation, and I wonder whether this can be fixed > > for other users in any (fast) way, upfront other users doing apt > > upgrade on their Xen hosts? > > > > My workaround for this ATM: install and pin previous grub-xen-host > > (grub-xen-host_2.04-20_amd64.deb, grub-xen-bin_2.04-20_amd64.deb, > > grub-common_2.04-20_amd64.deb). Probably the wrong way to fix it, but > > works for me so far(TM). > > > > In case this should be reported or added to something somewhere, > > please let me (a Debian bug reporting newbie) know. > > I would imagine a fix could follow quite quickly as it only requires > rebuilding with a filename added to a list of files not to have > their symbols stripped (or reverting the compatibility level change). The patch to fix the bug with the dh_strip override was identified six days ago in the bug report by a user, yet AFAICT the grub maintainers have not even acknowledged the existence of this bug yet to those who have contributed to the bug report on BTS. So I do not expect a fix very soon. The grub maintainers do not have the time or interest to fix it. Perhaps the Xen users could try to convince the Xen maintainers to do an nmu to fix it if the grub maintainers continue to ignore the bug, but I don't know if that breaks the etiquette that governs such things in the world of Debian developers - I am just a Debian user. Best regards, Chuck > > AFAICT apt-listbugs would have reported this to you before > the upgrade of grub-xen-host took place, as someone had reported > it on 22 Aug. So it might be worth installing apt-listbugs. > > Cheers, > David. >
Re: Currently on x11vnc, looking for reliable VNC solution?
On 9/7/22 10:11 PM, David wrote: > On Thu, 8 Sept 2022 at 11:44, Chuck Zmudzinski wrote: > > On 9/7/22 7:45 PM, David wrote: > > > On Thu, 8 Sept 2022 at 02:49, Chuck Zmudzinski > > > wrote: > > > > On 9/7/2022 12:13 PM, Chuck Zmudzinski wrote: > > > > > > > > I use the tigervnc-standalone-server which is in the Debian packages > > > > > archives. I use it only on a trusted LAN network so I don't need an > > > > > encrypted vnc connection either, and I can access it remotely from the > > > > > Internet by connecting to the LAN using a VPN (I use strongswan/IKEv2 > > > > > for the VPN server). The main configuration files are at ~/.vnc, and > > > > > there are tools to configure it such as vncpasswd. The most important > > > > > configuration file is ~/.vnc/xstartup, where you launch your DE or > > > > > window manager of your choice. > > > > > > > > You can launch the server from a terminal logged in as an ordinary > > > > > user > > > > > and the server runs as an ordinary user in the background so after you > > > > > start the server in a terminal you can exit that terminal session. > > > > > > > Actually, you *should* exit that terminal session, especially if it is > > > > a terminal window running in the same kind of session (gnome, lxde, etc) > > > > and as the same user that you plan to run in the VNC server. This is > > > > another limitation of the tigervnc-standalone-server: it does not > > > > connect > > > > to an already running X11 session but instead launches a new session as > > > > an ordinary user as specified in ~/.vnc/xstartup. > > > > > > > I have found that if I try to run two sessions as the same user, one > > > > over > > > > VNC and one on the local desktop, it does not work too well, at least > > > > with the current version of gnome, probably because there is not good > > > > enough separation of the various user processes that gnome starts for > > > > each user session. > > > > > > Hi, > > > > > > Regarding your final sentence, I wonder if installing dbus-x11 instead of > > > dbus-user-session would improve that situation. > > > > > > Because of what I read in the 'Description' in the output of > > > 'apt show dbus-user-session'. > > > > > > > I have both dbus-user-session and dbus-x11 installed: > > > > chuckz@debian:~$ dpkg-query -l dbus* > > Desired=Unknown/Install/Remove/Purge/Hold > > | > > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > > ||/ NameVersion Architecture Description > > +++-===---= > > ii dbus1.12.20-2amd64simple interprocess > > messaging system (daemon and utilities) > > un dbus-bin (no description > > available) > > un dbus-daemon (no description > > available) > > un dbus-session-bus (no description > > available) > > un dbus-session-bus-common (no description > > available) > > un dbus-system-bus (no description > > available) > > un dbus-system-bus-common(no description > > available) > > ii dbus-user-session 1.12.20-2amd64simple interprocess > > messaging system (systemd --user integration) > > ii dbus-x111.12.20-2amd64simple interprocess > > messaging system (X11 deps) > > > > I don't know how systemd handles the case when one user has two gnome > > sessions running at the same time or if it is possible to make it behave > > better in that case. I also don't know if installing dbus-session-bus or > > dbus-system-bus might help. If anyone has any tips to improve the way it > > runs in that case, I could try them out. > > The 'Description' to which I referred you says: > To retain dbus' traditional session semantics, in which login sessions > are artificially isolated from each other, remove this package and install > dbus-x11 instead > > Note: "remove this package". > I just tried my system with the dbus-user-session package removed, and it still does not run two gnome sessions of the same user very well. After removing the dbus-user-session package with the dbus-x11 package still installed, I started the tigervnc server which started a gnome user session, and then when I logged into another gnome session on the local display as the same user, the session on the local display started normally but in the process of starting the session on the local display the tigervnc server died. So I avoid running two gnome sessions as the same user at the same time on the same machine, and I don't think the feature of running two sessions at the same time as the same user on the same machine is a feature that is needed all that much, it is just a curiosity for me. Best regards, Chuck
Re: Currently on x11vnc, looking for reliable VNC solution?
On 9/7/22 7:45 PM, David wrote: > On Thu, 8 Sept 2022 at 02:49, Chuck Zmudzinski wrote: > > On 9/7/2022 12:13 PM, Chuck Zmudzinski wrote: > > > > I use the tigervnc-standalone-server which is in the Debian packages > > > archives. I use it only on a trusted LAN network so I don't need an > > > encrypted vnc connection either, and I can access it remotely from the > > > Internet by connecting to the LAN using a VPN (I use strongswan/IKEv2 > > > for the VPN server). The main configuration files are at ~/.vnc, and > > > there are tools to configure it such as vncpasswd. The most important > > > configuration file is ~/.vnc/xstartup, where you launch your DE or > > > window manager of your choice. > > > > You can launch the server from a terminal logged in as an ordinary user > > > and the server runs as an ordinary user in the background so after you > > > start the server in a terminal you can exit that terminal session. > > > Actually, you *should* exit that terminal session, especially if it is > > a terminal window running in the same kind of session (gnome, lxde, etc) > > and as the same user that you plan to run in the VNC server. This is > > another limitation of the tigervnc-standalone-server: it does not connect > > to an already running X11 session but instead launches a new session as > > an ordinary user as specified in ~/.vnc/xstartup. > > > I have found that if I try to run two sessions as the same user, one over > > VNC and one on the local desktop, it does not work too well, at least > > with the current version of gnome, probably because there is not good > > enough separation of the various user processes that gnome starts for > > each user session. > > Hi, > > Regarding your final sentence, I wonder if installing dbus-x11 instead of > dbus-user-session would improve that situation. > > Because of what I read in the 'Description' in the output of > 'apt show dbus-user-session'. > I have both dbus-user-session and dbus-x11 installed: chuckz@debian:~$ dpkg-query -l dbus* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===---= ii dbus 1.12.20-2 amd64 simple interprocess messaging system (daemon and utilities) un dbus-bin (no description available) un dbus-daemon (no description available) un dbus-session-bus (no description available) un dbus-session-bus-common (no description available) un dbus-system-bus (no description available) un dbus-system-bus-common (no description available) ii dbus-user-session 1.12.20-2 amd64 simple interprocess messaging system (systemd --user integration) ii dbus-x11 1.12.20-2 amd64 simple interprocess messaging system (X11 deps) I don't know how systemd handles the case when one user has two gnome sessions running at the same time or if it is possible to make it behave better in that case. I also don't know if installing dbus-session-bus or dbus-system-bus might help. If anyone has any tips to improve the way it runs in that case, I could try them out. Best regards, Chuck
Re: Currently on x11vnc, looking for reliable VNC solution?
On 9/7/2022 12:13 PM, Chuck Zmudzinski wrote: > On 9/7/2022 4:41 AM, piorunz wrote: > > On 07/09/2022 05:58, notoneofmyseeds wrote: > > > On 07.09.22 06:19, Alexander V. Makartsev wrote: > > > > > >>> > > >> I've switched to NoMachine [1] a long time ago. > > >> It has all features I need, which are multi-platform and cross-OS > > >> support, public key authentication, reliable file transfer between > > >> hosts, and completely free no strings attached license for personal use. > > > > > > and the there's anydesk, with conditions just as nomachine. > > > > > > anydesk.com > > > > > >> > > >> > > >> [1] https://www.nomachine.com/ > > > > Thanks for your replies guys. These solutions are overkill to my needs, > > I just need reliable LAN access from one machine to another, as for WAN > > access I already have ssh tunnel which tunnels all traffic I want if > > need be. So, I don't think I need external, commercial, not open source > > solution for my simple remote access. I'd rather fix VNC server I have > > right now, or switch to different VNC server. Anyone has experience with > > VNC, or similar LAN protocols, which work? Thanks in advance. > > > > -- > > With kindest regards, Piotr. > > > > ⢀⣴⠾⠻⢶⣦⠀ > > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ > > ⠈⠳⣄ > > > > I use the tigervnc-standalone-server which is in the Debian packages > archives. I use it only on a trusted LAN network so I don't need an encrypted > vnc connection either, and I can access it remotely from the Internet by > connecting to the LAN using a VPN (I use strongswan/IKEv2 for the VPN > server). The main configuration files are at ~/.vnc, and there are tools to > configure it such as vncpasswd. The most important configuration file is > ~/.vnc/xstartup, where you launch your DE or window manager of your choice. > > You can launch the server from a terminal logged in as an ordinary user and > the server runs as an ordinary user in the background so after you start the > server in a terminal you can exit that terminal session. Actually, you *should* exit that terminal session, especially if it is a terminal window running in the same kind of session (gnome, lxde, etc) and as the same user that you plan to run in the VNC server. This is another limitation of the tigervnc-standalone-server: it does not connect to an already running X11 session but instead launches a new session as an ordinary user as specified in ~/.vnc/xstartup. I have found that if I try to run two sessions as the same user, one over VNC and one on the local desktop, it does not work too well, at least with the current version of gnome, probably because there is not good enough separation of the various user processes that gnome starts for each user session. So when I use the tigervnc standalone VNC session, I log out of the session on the local desktop for the user that is running the VNC server, and if I am going to use the local desktop session as the same user that is using the VNC server, I kill the VNC server first, so there will not be two gnome sessions running as the same user. > With the vnc port (usually 5901) open in the firewall, you can connect to the > server and start your apps, and once you have apps running, it will keep them > running in the session until you kill the server. I use it with gnome-session > with Xorg (I tried wayland session a while back and Xorg seemed more stable), > and it works adequately for my needs on stable, testing, and sid. It works > with both VNC viewers I have tried: RealVNC on Windows, and tigervnc-viewer > on Debian. > > There is one slight annoyance that I live with: With the gnome-session > desktop, there are some apps and settings that will require me to enter my > password when I first use that setting or app, such as setting up a color > profile, using the keyring, and starting the Brave browser. This could > probably be fixed with appropriate commands in the ~/.vnc/xstartup file, but > I have not tried debugging it and I just enter the password when asked by the > gnome desktop and after the first time for each app or setting it won't ask > again until I kill the server and restart it. > > Best regards, > > Chuck >
Re: Currently on x11vnc, looking for reliable VNC solution?
On 9/7/2022 4:41 AM, piorunz wrote: > On 07/09/2022 05:58, notoneofmyseeds wrote: > > On 07.09.22 06:19, Alexander V. Makartsev wrote: > > > >>> > >> I've switched to NoMachine [1] a long time ago. > >> It has all features I need, which are multi-platform and cross-OS > >> support, public key authentication, reliable file transfer between > >> hosts, and completely free no strings attached license for personal use. > > > > and the there's anydesk, with conditions just as nomachine. > > > > anydesk.com > > > >> > >> > >> [1] https://www.nomachine.com/ > > Thanks for your replies guys. These solutions are overkill to my needs, > I just need reliable LAN access from one machine to another, as for WAN > access I already have ssh tunnel which tunnels all traffic I want if > need be. So, I don't think I need external, commercial, not open source > solution for my simple remote access. I'd rather fix VNC server I have > right now, or switch to different VNC server. Anyone has experience with > VNC, or similar LAN protocols, which work? Thanks in advance. > > -- > With kindest regards, Piotr. > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ > ⠈⠳⣄ > I use the tigervnc-standalone-server which is in the Debian packages archives. I use it only on a trusted LAN network so I don't need an encrypted vnc connection either, and I can access it remotely from the Internet by connecting to the LAN using a VPN (I use strongswan/IKEv2 for the VPN server). The main configuration files are at ~/.vnc, and there are tools to configure it such as vncpasswd. The most important configuration file is ~/.vnc/xstartup, where you launch your DE or window manager of your choice. You can launch the server from a terminal logged in as an ordinary user and the server runs as an ordinary user in the background so after you start the server in a terminal you can exit that terminal session. With the vnc port (usually 5901) open in the firewall, you can connect to the server and start your apps, and once you have apps running, it will keep them running in the session until you kill the server. I use it with gnome-session with Xorg (I tried wayland session a while back and Xorg seemed more stable), and it works adequately for my needs on stable, testing, and sid. It works with both VNC viewers I have tried: RealVNC on Windows, and tigervnc-viewer on Debian. There is one slight annoyance that I live with: With the gnome-session desktop, there are some apps and settings that will require me to enter my password when I first use that setting or app, such as setting up a color profile, using the keyring, and starting the Brave browser. This could probably be fixed with appropriate commands in the ~/.vnc/xstartup file, but I have not tried debugging it and I just enter the password when asked by the gnome desktop and after the first time for each app or setting it won't ask again until I kill the server and restart it. Best regards, Chuck
Re: networking.service: start operation timed out [SOLVED]
On 8/31/22 11:03 AM, Jeremy Ardley wrote: > On 31/8/22 10:45 pm, Chuck Zmudzinski wrote: > > > > I don't use haproxy but I see there is a package for it in the Debian > > repos. I think what you are seeing should be reported as a bug in > > haproxy if you are using the Debian packaged version. The haproxy > > package should start haproxy at the appropriate time during boot, > > and systemd provides the ability to make services such as haproxy > > depend on certain systemd targets being reached before it tries to > > start, such as the network-online target which I think would be > > enough for haproxy to start. But in any case, you might report a bug > > in haproxy and see if the package maintainers can help you out if > > you are using the Debian packaged version. > > > haproxy does retry three (?) times over a period. The problem is my upstream > provider can take up to 10 minutes to provide a dhcp address and ipv6 RA. > > The network service does start correctly, but lapses into a retry mode when > it can't get the full delegation at once. > > haproxy requires a configured interface for it to bind to. Typically this > means bind to an IP address and port. If the solicitation to the upstream > router hasn't happened, there is no IP and port to bind. haproxy does have an > (undocumented?) retry feature to repeatedly try to bind over a period. > > If any bug request is to be logged, perhaps it should be for haproxy to have > configurable binding options including number of retries or time elapsed? > > Jeremy > It sounds like it should be either a request for better documentation on configuring retries over a long time period from the haproxy documentation or a bug with wishlist severity if haproxy currently cannot handle such a long time to wait for the address to be configured by the upstream router. It also seems to be a ridiculously long time (ten minutes) for your provider to configure your interface. I would look for a different provider if they can't or won't fix it. Chuck
Re: networking.service: start operation timed out [SOLVED]
On 8/30/22 8:49 PM, Jeremy Ardley wrote: > On 30/8/22 9:56 am, Ross Boylan wrote: > > > > Now everything just works. > > > > Thanks again to everyone. > > > > There are probably some general lessons, though I'm not sure what they > > are. Clearly the systemd semantics tripped me up; it's kind of an odd > > beast. I understand one of its major goals was to allow startup to > > proceed in parallel, which is pretty asynchronous. But it has to > > assure that certain things happen in a certain order, which results in > > some things being synchronous and blocking. I'm surprised that a tool > > intended for use from the command line (systemctl) is blocking. > > > > Ross > > > > One of my problems with systemd is the that name resolution is by > default done by resolved. If resolved was bug free that might be O.K. > but it's not - and in a production environment it's not a safe option. > > A result of the use of resolved is the start-up and dependency logic. If > you start doing things outside of the plan, you run into all sorts of > problems. I use bind9 on my various machines and have had to go to some > lengths to take resolved out of the equation. > > On a similar but different topic. I have a router that connects to an > upstream server and also runs haproxy. The upstream connection uses DHCP > and IPv6 solicitation. The problem is haproxy fails to start when the > upstream connection is not established and configured quickly enough. > What would be very helpful is a systemd way to start haproxy when the > network is established 'as configured'. So far all I can do is run a > cron job to see if haproxy is running and if not, try and restart it. > There has to be a better way. > You are right, you should not need to use a cron job to start a service like haproxy. I don't use haproxy but I see there is a package for it in the Debian repos. I think what you are seeing should be reported as a bug in haproxy if you are using the Debian packaged version. The haproxy package should start haproxy at the appropriate time during boot, and systemd provides the ability to make services such as haproxy depend on certain systemd targets being reached before it tries to start, such as the network-online target which I think would be enough for haproxy to start. But in any case, you might report a bug in haproxy and see if the package maintainers can help you out if you are using the Debian packaged version. Best regards, Chuck
Re: Virtual Machines
On 8/22/2022 8:50 AM, Tom Browder wrote: > Can anyone recommend a good book on the general topic of VMs? Or one on a > specific VM stack (using Linux as base)? > > Thanks. > > -Tom This looks like a comprehensive and reasonably up-to-date online book: https://linuxhandbook.com/virtualization/ Best regards, Chuck
Re: Comments on upgrade steps from one version of Debian to another
On 8/20/2022 3:48 PM, John Boxall wrote: > I created an upgrade script based on something I found a few years ago > that indicated the steps to follow to upgrade from one version of Debian > to another (e.g. Buster 10 to Bullseye 11). As I am going to need to run > this script at some point (I am still running Buster/10 on my systems), > I thought I'd ask the Debian user brain trust to comment/critique the > scripted steps. So here they are: > > > ### Start > apt -y install aptitude > aptitude search \'~o\' > apt update > apt -y upgrade > apt -y full-upgrade > dpkg -C > apt-mark showhold > # > Update sources.list > # > Update files in sources.list.d > (I don't even have this part started yetdidn't know I needed it the > last time I ran it) > # > apt-get check > apt update > apt list --upgradable > apt-get check > apt -y upgrade > apt -y full-upgrade > aptitude search \'~o\' > ### End > > Thoughts/critique/criticism/flames/etc > Hi John, here are my suggestions: You can use apt, apt-get, or aptitude to run the commands that do most of the work, and in your script you chose apt for that task. I recall reading that they do not all use the same algorithm to determine which packages to upgrade and in what order, at each stage of the upgrade. I think I read somewhere that aptitude has the best algorithm, but apt-get is more suitable for a script. I don't remember if there are advantages or disadvantages to using apt. So you should do a little research to try to find the most up-to-date information about the pros and cons of the different apt related tools. The Debian wiki has a page on that, I think. Also, you might want to make sure you record the upgrade session in a logfile so you can examine what the script actually did in case there are problems. And of course, backup or take a snapshot beforehand so you can restore the system back to a working state in case things get broken badly. HTH, Chuck
Re: Why are some Debian bugs ignored for a long time?
On 8/20/22 4:28 PM, Stefan Monnier wrote: > Chuck Zmudzinski [2022-08-20 16:20:21] wrote: > > That's a fair point. It may not be so easy for me to work on a bug that > > does not affect > > my systems, but I am willing to help with bugs important to the Debian > > project now, as > > the bookworm development process continues. I will take some time and see > > if I can > > help out with some other open bugs that do not directly affect my systems. > > Such bugs > > can be found by querying BTS for bugs marked as critical or grave by the > > maintainer > > and bugs that are blocking a release, as these are the ones most important > > to the > > maintainers and developers. I don't know if I have the skills to fix such > > bugs which are > > probably not so easy to fix, but it wouldn't hurt to ask if there is > > anything I can do to > > help. One thing that is always helpful are testers to test the proposed > > fixes for open > > bugs, and I could help with that in cases when the bug affects a package on > > one or more > > of my systems, at least to tell the maintainer, "that proposed fix looks > > good, it does not > > break anything on my systems." > > Yes, there are many things one can do to help. E.g. several bugs are > misfiled (for example, sent to the Debian maintainer instead of being > sent to the package's developer even though the bug is unrelated to the > Debian packaging itself). Or often the bug report lacks information to > reproduce it. > > > Stefan > On Debian, the best thing users can do to help, AFAICT, is to run the testing distribution on non-critical systems to see if the development of the next stable Debian version is causing problems. The more people who run testing and give the developers feedback about problems on BTS, the more likely the stable version won't break someone's current setup when it is released and users start upgrading to the new stable version in larger numbers. Still, for this development process that Debian uses to be effective, when problems are reported to BTS, the developers and maintainers need to respond to the bugs that are reported and not ignore them. Best regards, Chuck
Re: Why are some Debian bugs ignored for a long time?
On 8/20/2022 2:06 PM, Stefan Monnier wrote: > > So that means "free" software written and maintained by volunteers will > > never be as > > stable and secure as software that is written by people who are paid by the > > hour. > > Not necessarily. Have you filed a bug report about a problem you > perceived in macOS, Windows, other your usual shrink wrapped software? > Has it always been fixed promptly? > > If you want your bugs to be fixed, you generally need resort to some > kind of support contract, which you can get for Free Software just as > easily as for proprietary software (probably more easily, actually). > > Notice also that the goal of Free Software is not to be technically > better (you may be confusing it for Open Source software), but > ethically better. > > I suspect most maintainers who don't respond promptly to bug reports > aren't happy about that fact: its demoralizing to be in charge of > something you can't devote the resources it really deserves. > > But note that *you* can help, by taking on some of the work, looking for > bugs that haven't gotten an answer yet and trying to address them. That's a fair point. It may not be so easy for me to work on a bug that does not affect my systems, but I am willing to help with bugs important to the Debian project now, as the bookworm development process continues. I will take some time and see if I can help out with some other open bugs that do not directly affect my systems. Such bugs can be found by querying BTS for bugs marked as critical or grave by the maintainer and bugs that are blocking a release, as these are the ones most important to the maintainers and developers. I don't know if I have the skills to fix such bugs which are probably not so easy to fix, but it wouldn't hurt to ask if there is anything I can do to help. One thing that is always helpful are testers to test the proposed fixes for open bugs, and I could help with that in cases when the bug affects a package on one or more of my systems, at least to tell the maintainer, "that proposed fix looks good, it does not break anything on my systems." Thanks, Chuck > I don't think anyone can do that for any random bug, but I'm pretty sure > most people on this list would be able to do that for at least one of > the pending bug reports. > > > Stefan >
Re: Why are some Debian bugs ignored for a long time?
On 8/20/2022 1:25 AM, to...@tuxteam.de wrote: > On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote: > > On 8/19/2022 4:44 PM, piorunz wrote: > > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > > > > > I have noticed that some Debian bugs are ignored for a long time [...] > > > > > > Hi Chuck, > > > > > > Maybe because developers/maintainers are not paid by the hour, but mere > > > volunteers, don't you think? > > There is another point: the package maintainer is very autonomous > in how (s)he does her thing. This has advantages and disadvantages. > > There are processes in place for resolving such situations as when > a maintainer becomes unresponsive (perhaps (s)he has moved on to > other things, perhaps (s)he is in some situation of distress). Among > others, there is the NMU [0]. > > This question comes up regularly in this list. Had you searched > the archives, you'd found things like this [1] with advice (hint: > this would leave developers more time for fixing bugs ;-) > > There is good advice by Jonathan Dowland in the linked thread on > how to do something about it. Want to give it a try? > > > So that means "free" software written and maintained by volunteers will > > never be as > > stable and secure as software that is written by people who are paid by the > > hour. > > This is, of course, nonsense. This would be only the case if > the instance giving out the cash had an interest on the software > being "stable and secure". Most of the time they have an interest > on the software being sold, or on it generating cash flow via > other means (gathering user data, for that to be sold, for example). > > So they will allocate their resources accordingly. I've worked > in the belly of big corps for a while and I assure you that my > boss wouldn't allow me to fix a bug unless (s)he could justify > to their bosses that the 1400 dollars "spent" on this are coming > back in some way. There are plenty of "volunteers" for free software projects that also work, as you say, in the "belly of big corps." Are you suggesting these "volunteers" will ignore bugs in free software projects because their boss does not want them to fix the bugs in the free project and force users to buy a paid version of the project? Best regards, Chuck
Re: Why are some Debian bugs ignored for a long time?
On 8/20/2022 1:25 AM, to...@tuxteam.de wrote: > On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote: > > On 8/19/2022 4:44 PM, piorunz wrote: > > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > > > > > I have noticed that some Debian bugs are ignored for a long time [...] > > > > > > Hi Chuck, > > > > > > Maybe because developers/maintainers are not paid by the hour, but mere > > > volunteers, don't you think? > > There is another point: the package maintainer is very autonomous > in how (s)he does her thing. This has advantages and disadvantages. > > There are processes in place for resolving such situations as when > a maintainer becomes unresponsive (perhaps (s)he has moved on to > other things, perhaps (s)he is in some situation of distress). Among > others, there is the NMU [0]. I know about nmu, and I submitted one once but withdrew it because the package maintainer did eventually indicate a fix the problem was coming once I sent out the nmu. > > This question comes up regularly in this list. Had you searched > the archives, you'd found things like this [1] with advice (hint: > this would leave developers more time for fixing bugs ;-) > > There is good advice by Jonathan Dowland in the linked thread on > how to do something about it. Want to give it a try? > > > So that means "free" software written and maintained by volunteers will > > never be as > > stable and secure as software that is written by people who are paid by the > > hour. > > This is, of course, nonsense. This would be only the case if > the instance giving out the cash had an interest on the software > being "stable and secure". Most of the time they have an interest > on the software being sold, or on it generating cash flow via > other means (gathering user data, for that to be sold, for example). > > So they will allocate their resources accordingly. I've worked > in the belly of big corps for a while and I assure you that my > boss wouldn't allow me to fix a bug unless (s)he could justify > to their bosses that the 1400 dollars "spent" on this are coming > back in some way. > > Witness the whole history of Microsoft software with its incredible > ecosystem of malware, and you'll see how wrong your idea is :) > > So each "world" has its upsides and (surprise!) its downsides. > > That doesn't mean I wouldn't like to see projects like Debian > better funded, mind you. There are also people thinking about > this. There are companies which sponsor Debian, there are > companies which let employees work for Debian on their company > time; one seemingly successful example is Freexian [2], which > offers services by keeping alive older versions of Debian. > > I get you want to contribute? Yes, that's what mystifies me. I don't know why Debian ignores someone who wants to contribute time to help the project. In another case, the bug was upstream and although I reported the bug on Debian first, marked it 'patch' and 'upstream' in the BTS, it was still being ignored, so I just submitted the patch directly to upstream who accepted my patch. Usually upstream projects want and expect users to report bugs to the distro, not to the upstream project, for many good reasons that I need not explain here. Then the distro package maintainer, rather than the user, interacts with the upstream developers and maintainers. Of course if the distro maintainers ignore upstream bugs reported to the distro, the whole free software ecosystem will suffer, not just Debian. Best regards, Chuck > [0] https://wiki.debian.org/NonMaintainerUpload > [1] https://lists.debian.org/debian-user/2022/05/threads.html#00028 > [2] https://www.freexian.com/services/debian-lts.html >
Re: Why are some Debian bugs ignored for a long time?
On 8/19/2022 9:18 PM, Andy Smith wrote: > Hi Chuck, > > On Fri, Aug 19, 2022 at 08:20:21PM -0400, Chuck Zmudzinski wrote: > > On 8/19/2022 6:59 PM, Andy Smith wrote: > > > Volunteers cannot be forced to do work, else they are not > > > volunteers. > > > > The fact that Debian is created by volunteers and therefore the chances are > > high that users might run into problems and not get help from the volunteers > > who alone have the power to fix the problems is a fact that Debian users, > > and > > all users of free software, need to keep in mind. > > A danger here is that you write as if this is a particular problem > for Debian, but I think you've merely stated a truism for every > volunteer effort of any kind. > > People do sometimes need reminding that they are relying on a > volunteer effort, however. > > > I am going to try some other projects and find out by experience > > where the consideration for the user has a higher priority than in > > Debian. > > I am not going to tell you that Debian is the best Linux > distribution for you or anyone specific, though you could perhaps > expect responses along those lines given that we're having this > conversation in a Debian space. > > The thing is though, you can experience a problem within one project > that is frustrating and demotivating and so move to another project > that does not have that particular problem, only to later experience > a different problem in the next project that is also frustrating and > demotivating. Only you can decide which one overall suits you best; > what's certain is that nothing is going to be perfect. Of course. > > If any Linux distribution were asked, "do you consider the user > experience to be a high priority?" they are probably all going to > answer, "yes!" But in reality there will always be some decisions > (or lack of decisions) made where some number of users feel they > were mistreated. > > If you have the time and interest to look at other distributions > it's probably not going to be wasted time, anyway, if only to > compare and contrast. > > Cheers, > Andy > Thanks for the feedback, I do have the time to experiment with other distros and obviously I will use what best serves my goals. Debian still has the advantage that I have been using it for quite a while, have invested much time in tweaking it, and it still works fairly well for me. But at this point, I don't know if I will upgrade to bookworm or move to another distro before bookworm is released. Best regards, Chuck
Re: Why are some Debian bugs ignored for a long time?
On 8/19/2022 6:59 PM, Andy Smith wrote: > Hello, > > On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote: > > On 8/19/2022 4:44 PM, piorunz wrote: > > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > > I have noticed that some Debian bugs are ignored for a long time, > > > > sometimes even when the person who submitted the bug offered a patch. > > > > The Debian developers/maintainers sometimes don't even reply and > > > > therefore never explain why the proposed patch cannot be applied. Why > > > > is that the case with Debian developers/maintainers? > > > > > > Hi Chuck, > > > > > > Maybe because developers/maintainers are not paid by the hour, but mere > > > volunteers, don't you think? > > > > > you are saying if a Debian user experiences a bug in Debian > > software, Debian developers/maintainers do not have to fix it. > > That is a direct consequence of the meaning of the term "volunteer"; > you may as well have said, "water is wet". Volunteers cannot be > forced to do work, else they are not volunteers. The fact that Debian is created by volunteers and therefore the chances are high that users might run into problems and not get help from the volunteers who alone have the power to fix the problems is a fact that Debian users, and all users of free software, need to keep in mind. > > > If Debian developers/maintainers actively refuse to fix some bugs that > > inevitably arise > > by ignoring them, why would anyone depend on Debian software for anything > > important? > > I would argue that the situation is similar (and often worse) in > every other free software project. In Linux itself, I think it is *much* better than in Debian. I am going to try some other projects and find out by experience where the consideration for the user has a higher priority than in Debian. > > I would also argue that while you may pay a software vendor to care > about your use case, that can also come with different issues. > > So really, life is not perfect, and we all do what we can to cope > with that. Things are not perfect in Debian nor elsewhere both > within and outside the free software world. > > I think I know some of the bugs that you are referring to as I keep > on eye on those developments. A gentle ping on the relevant bugs to > ask where things are may be appropriate.That's really the strongest > thing you can do. I do that and I am ignored. I am not holding my breath waiting for a response from the relevant developers and maintainers. However, it would be a pleasant surprise if they *did* respond and I would be grateful if they did. I just don't think volunteers trying to help Debian but who ignore users who report bugs in Debian is over the long term a good thing for Debian. > Others may be tempted to try to drag more info out > of you to determine what the exact history is here and who is > right/wrong, but I don't think that will help anyone in these > particular cases. We agree on that point. Best regards, Chuck
Re: Why are some Debian bugs ignored for a long time?
On 8/19/2022 6:43 PM, Timothy M Butterworth wrote: > > > On Fri, Aug 19, 2022 at 6:40 PM Chuck Zmudzinski > wrote: > > On 8/19/2022 6:20 PM, Timothy M Butterworth wrote: > > > > > > On Fri, Aug 19, 2022 at 5:07 PM Chuck Zmudzinski > wrote: > > > > On 8/19/2022 4:44 PM, piorunz wrote: > > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > > > > > I have noticed that some Debian bugs are ignored for a long > time, sometimes even when the person who submitted the bug offered a patch. > The Debian developers/maintainers sometimes don't even reply and therefore > never explain why the proposed patch cannot be applied. Why is that the case > with Debian developers/maintainers? > > > > > > Hi Chuck, > > > > > > Maybe because developers/maintainers are not paid by the hour, > but mere > > > volunteers, don't you think? > > > > Debian Stable usually only ships security and stability patches. > > > > > > So that means "free" software written and maintained by volunteers > will never be as > > stable and secure as software that is written by people who are > paid by the hour. > > > > Freexian has developers that are paid by the hour to work on Debian, > anyone who wants with cash to spare can purchase some hours to have work done > on packages of their choosing. > > > > * 2 hours pack: 240 EUR + VAT (120 EUR/hour) > > * 5 hours pack: 600 EUR + VAT (120 EUR/hour) > > * 10 hours pack: 1150 EUR + VAT (115 EUR/hour) > > * 20 hours pack: 2300 EUR + VAT (115 EUR/hour) > > * 50 hours pack: 5500 EUR + VAT (110 EUR/hour) > > > > That's good to know. Thanks. Presumably the work they do would be > contributed back > to Debian for the benefit of all. I am curious if they would be able to > help in a case when > a bug with a known fix has been ignored for a long time. I would prefer > that Debian would > just fix the bug instead of having to pay someone to tell Debian they > should fix the bug. > > I could also just migrate to Fedora since their distro does not have the > bug and I wouldn't > have to pay anyone for my system to work using Fedora. > > Distro hopping is one of the best things about Linux, I personally switch > between Debian, openSUSE and Fedora. One day I want to roll my own distro. I > am planning on making a stripped down debian focusing on KDE Plasma and KDE > Apps. One DE one hardware platform. Yes, the many distros is a nice thing about Linux, and now it looks like it is time for me to start hopping from Debian to other distros when necessary. Sorry, I forgot to reply-to the list, so I am bringing the discussion back to the list. Thanks, Chuck > > > Best regards, > > Chuck > > > > > > > > > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ > > ⠈⠳⣄⠀⠀ > > > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ > ⠈⠳⣄⠀⠀
Re: Why are some Debian bugs ignored for a long time?
On 8/19/2022 4:44 PM, piorunz wrote: > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > I have noticed that some Debian bugs are ignored for a long time, sometimes > > even when the person who submitted the bug offered a patch. The Debian > > developers/maintainers sometimes don't even reply and therefore never > > explain why the proposed patch cannot be applied. Why is that the case with > > Debian developers/maintainers? > > Hi Chuck, > > Maybe because developers/maintainers are not paid by the hour, but mere > volunteers, don't you think? So that means "free" software written and maintained by volunteers will never be as stable and secure as software that is written by people who are paid by the hour. That is, Debian software can *never* be as stable and secure as software that is written and maintained by people who are paid by the hour. Not only that, you are saying if a Debian user experiences a bug in Debian software, Debian developers/maintainers do not have to fix it. That's fine, but... If Debian developers/maintainers actively refuse to fix some bugs that inevitably arise by ignoring them, why would anyone depend on Debian software for anything important? Best regards, Chuck
Why are some Debian bugs ignored for a long time?
Hello, I have noticed that some Debian bugs are ignored for a long time, sometimes even when the person who submitted the bug offered a patch. The Debian developers/maintainers sometimes don't even reply and therefore never explain why the proposed patch cannot be applied. Why is that the case with Debian developers/maintainers? Best regards, Chuck
Re: Windows on VMware on Deb 11: safely usable?
On 8/17/2022 10:34 AM, hdv@gmail wrote: > On 2022-08-17 12:53, Tom Browder wrote: > > Unfortunately, I have to have a Windows host. I have given up dual > > hosting because of the pain, so I am using a dedicated Win 10 box and a > > Deb laptop. > > > > I would love to run Windows on a VM on Debian iff I can have it be > > reliable enough to use with reasonable response (no games, just Office > > 360, IO Drive, H Block, and such). I haven't kept up with the VM world > > but a quick search shows VMware might be a good choice. > > > > Anyone using such a rig for the real world (i.e., not testing or as a > > hobby)? If it is reliable, I plan to get a hefty SilentPC to run my > > primary digital duopoly. > > > > Thanks. > > > > -Tom > > Please note that VirtualBox isn't in the official repository. There is a > reason for that: Oracle won't/can't cooperate with the Debian Security Team. > > As for VMWare: when I still used it, a major disadvantage was that you > had to fuss around with the kernel every time there was an update. That > really was a major PITA. I don't know if that still is the case with > VMWare, but I do know I have no such trouble with libvirt. At all. I don't see much discussion about libvirt on debian-use, which I presume is KVM/Qemu VMs. That means one of two things: either 1) no one is using it, or 2) it works so well it is good enough for the real world and no one needs to ask questions about it on debian-user. My advice - buy your Silent PC, Install Debian on it, and use KVM/Qemu on it to install Windows. That will use supported Debian free software to provide the virtualization environment for your Windows installation. If for some reason KVM/Qemu/libvirt does not work, then install Windows Pro on the Silent PC and run Debian in Hyper-V. AFAIK, MS fully supports Debian in Hyper-V, and that would also most likely be a reliable setup also for the real world to run Debian 11 and Windows 10/11 simultaneously. Chuck
Re: Windows on VMware on Deb 11: safely usable?
On 8/17/2022 6:53 AM, Tom Browder wrote: > Unfortunately, I have to have a Windows host. I have given up dual hosting > because of the pain, so I am using a dedicated Win 10 box and a Deb laptop. > > I would love to run Windows on a VM on Debian iff I can have it be reliable > enough to use with reasonable response (no games, just Office 360, IO Drive, > H Block, and such). I haven't kept up with the VM world but a quick search > shows VMware might be a good choice. > > Anyone using such a rig for the real world (i.e., not testing or as a hobby)? > If it is reliable, I plan to get a hefty SilentPC to run my primary digital > duopoly. > > Thanks. > > -Tom I have this working now with Xen/Qemu, Deb 11, and Windows 10, but I would not recommend that for the real world, since sometimes updates and such break it. I don't know about VMware on Debian, I suppose it might work, you can inquire with VMware to see how much support they provide for VMware on Debian. Also, KVM/Qemu users might be able to weigh in with how viable that is as an option to run Windows in a VM on Debian for the real word. And the other option I know about is Virtualbox, which I also think can run on Debian and supports Windows VMs. Best regards, Chuck
Re: Help: disk swap
On 7/27/2022 1:51 PM, Erik Mathis wrote: > I would look at the UEFI vs BIOS boot options in the "backup" server and > compare it to the "broken" server and make sure they are the same. Also check > for BIOS updates and such. > > > -Erik- > > > On Wed, Jul 27, 2022 at 7:59 AM tony wrote: > > Hi, > > I turned on my main home server after a few weeks absence, and got > smoke from its power supply. Fortunately, I have a backup system, which > does work; both are running Debian 10, so I swapped use to that machine. > and am able to work with that, but some of the files and settings are a > bit out of date. > > I decided to move the disk from the broken machine to the backup, but on > booting I'm dropped into a grub screen saying disk id not > found. Not entirely surprising perhaps. > > So, how do I get it to recognize, and boot from the old disK. > > Cheers, Tony > I have used the following procedure to fix booting from a disk that causes the system to drop to the grub shell instead of booting normally: When in the grub shell, type ls, and you will see a list of the available disks and partitions. You will see items like (hd0,gpt1) which would be the first gpt partition on the first disk. Then you can list the files in that partition using 'ls (hd0,gpt1)/'. You should then look for the partition with the boot/grub/grub.cfg file, and then use the configfile command from the grub shell to load the grub configuration on the disk from the broken machine which should allow you to boot the Debian system that is on that disk. For example, if the grub.cfg file is on (hd0,gpt1), then you do: grub> configfile (hd0,gpt1)/boot/grub/grub.cfg Hopefully you will see the normal grub menu giving you the option to select on OS to boot, and hopefully you will be able to boot the Debian that is on the disk from the broken machine. If you can get the Debian system on the disk from the broken machine running, then you will need to reinstall grub to update your grub so it can boot using the disk from the broken machine without dropping to the grub shell. For example, If you use efi, you will need to reinstall grub-efi-amd64-bin or maybe grub-efi-amd64-bin-signed for secure boot, and after that it should boot the disk from the broken machine without dropping to the grub shell. Chuck
Re: TBird mail (was: user perms)
On 6/15/22 7:14 AM, Felix Miata wrote:
> gene heskett composed on 2022-06-15 06:34 (UTC-0400):
>
> > What the heck is this vertical bar it uses for a quote level
>
> That's taken care of here with one or both of these two entries in prefs.js
> in the
> profiledir:
>
> user_pref("mail.quoteasblock", false);
> user_pref("mail.quoted_graphical", false);
>
> I haven't noticed whether or not in GUI preferences if either has a
> counterpart.
I also use this setting to help get rid of the vertical bar:
user_pref("mailnews.send_plaintext_flowed", false);
and I take care to check Options-> Delivery Format is set to
"Plain Text Only" before sending a message.
Re: disable IPv6 debian
On 4/15/2022 6:58 PM, Andy Smith wrote: Hello, On Fri, Apr 15, 2022 at 10:34:25AM -0400, Chuck Zmudzinski wrote: I have an issue with a few websites that seem to hang with ipv6 If you happen to know their IPv6 addresses and can trust that those assignments will remain stable then you may prefer instead to add prohibited routes for these, e.g. # ip route add prohibit 2001:db8::/32 Your web browser will then fall back to using the IPv4 results that it gets from DNS. Cheers, Andy Thank you, Andy. I will try this if I find the addresses of the websites are stable. Regards, Chuck
Re: disable IPv6 debian
On 4/15/22 8:10 AM, wilson wrote: no. it's the Hadoop system, which has the possible issue with ipv6. thanks I would check the documentation for Hadoop - does it have an option to disable ipv6? I would just disable ipv6 for the app that has the issue with ipv6, not for the whole system. I also note that according to the Debian Wiki, Debian does not provide Hadoop packages: https://wiki.debian.org/Hadoop Regards, Chuck
Re: disable IPv6 debian
On 4/15/22 12:08 PM, Tim Woodall wrote: On Fri, 15 Apr 2022, Greg Wooledge wrote: On Fri, Apr 15, 2022 at 11:21:46AM -0400, Chuck Zmudzinski wrote: Another improvement to the script would be to have the script toggle the default route on or off, depending on the existence or not of the default route, for the case when there is no argument to the script. That requires some way to *determine* the current state. Parsing the routing table, perhaps? If you could tell us how to do that, it might help. Try this (untested as I'm remote and don't want to remove my default route!) [[ -z "$( ip -6 route show exact default )" ]] && echo no Hopefully will print no if there is no default route. Tim. This works well to determine the state and also prints a useful message if the expected argument is not present: #!/bin/bash if [ "$1" == on ] then ip -6 route | grep default > /dev/null || \ ip -6 route add default via 2602:304:cef3:a430:d250:99ff:fe0b:b810 dev eth0 elif [ "$1" == off ] then ip -6 route | grep default > /dev/null && ip -6 route delete default else echo "The script ipv6 requires either on or off as the argument." fi I tested all four cases: 1. There is no default route, and the argument is on 2. There is no default route, and the argument is off 3. There is a default route, and the argument is on 4. There is a default route, and the argument is off Works as expected. Regards, Chuck
Re: disable IPv6 debian
On 4/15/22 11:12 AM, Chuck Zmudzinski wrote: On 4/15/2022 10:50 AM, Greg Wooledge wrote: On Fri, Apr 15, 2022 at 10:34:25AM -0400, Chuck Zmudzinski wrote: user@debian:~$ cat ipv6 #!/bin/bash if [ $1 == "on" ] then ip -6 route add default via dev elif [ $1 == "off" ] then ip -6 route delete default fi Quotes are in the wrong place. The [ builtin command follows the ordinary parsing rules, which means an unquoted $1 argument will be subject to word splitting and filename expansions. In simpler terms, it will blow up if $1 is empty or contains whitespace characters or globbing characters. The quotes need to go around "$1", not around string constants. if [ "$1" == on ] You are right, with no arguments I get this: ./ipv6: line 2: [: ==: unary operator expected ./ipv6: line 5: [: ==: unary operator expected I did not write the script with unexpected values or whitespace for the argument in mind. It is a simple script that works as expected if the argument is what the script is designed for, either 'on' or 'off'. Of course the script is improved as you suggest to not dump the error message when there is no argument and is also further improved with error and help messages to handle the cases when the argument is not as designed or contains whitespace, as you point out. I have updated my script with your suggestion. Thanks! Chuck Another improvement to the script would be to have the script toggle the default route on or off, depending on the existence or not of the default route, for the case when there is no argument to the script. Regards, Chuck
Re: disable IPv6 debian
On 4/15/2022 10:50 AM, Greg Wooledge wrote: On Fri, Apr 15, 2022 at 10:34:25AM -0400, Chuck Zmudzinski wrote: user@debian:~$ cat ipv6 #!/bin/bash if [ $1 == "on" ] then ip -6 route add default via dev elif [ $1 == "off" ] then ip -6 route delete default fi Quotes are in the wrong place. The [ builtin command follows the ordinary parsing rules, which means an unquoted $1 argument will be subject to word splitting and filename expansions. In simpler terms, it will blow up if $1 is empty or contains whitespace characters or globbing characters. The quotes need to go around "$1", not around string constants. if [ "$1" == on ] You are right, with no arguments I get this: ./ipv6: line 2: [: ==: unary operator expected ./ipv6: line 5: [: ==: unary operator expected I did not write the script with unexpected values or whitespace for the argument in mind. It is a simple script that works as expected if the argument is what the script is designed for, either 'on' or 'off'. Of course the script is improved as you suggest to not dump the error message when there is no argument and is also further improved with error and help messages to handle the cases when the argument is not as designed or contains whitespace, as you point out. I have updated my script with your suggestion. Thanks! Chuck
Re: disable IPv6 debian
On 4/15/2022 8:10 AM, wilson wrote: no. it's the Hadoop system, which has the possible issue with ipv6. thanks I have an issue with a few websites that seem to hang with ipv6, so I don't want to disable ipv6 permanently but only temporarily when I want to access those sites. One class of sites are the Yahoo! Mail website app pages (including aol.com and att.net which are administered by Yahoo!) which seem to work much better with ipv4 only. I just temporarily delete the default ipv6 route when accessing those websites, and then re-enable it for other sites, with this little script: user@debian:~$ cat ipv6 #!/bin/bash if [ $1 == "on" ] then ip -6 route add default via dev elif [ $1 == "off" ] then ip -6 route delete default fi Then I do 'sudo ipv6 off' to disable the default ipv6 route and 'sudo ipv6 on' to re-enable it, assuming the ipv6 script is located in a directory listed in the PATH environment variable. Of course you need to insert the correct values for the default ipv6 gateway address and device for your network into the script which I redacted to protect the privacy of my ipv6 address and network configuration. It works well and causes the system to fallback to ipv4 for the public Internet without affecting ipv6 on my LAN which still functions correctly without a default ipv6 route. Your application (Hadoop) may be different, but if you only need to disable ipv6 for a certain network or class of networks, or only temporarily, deleting the ipv6 route to that network or class of networks or to the default route might be a solution for your issue. Regards, Chuck
Re: Does this happen often with sid?
On 3/29/22 3:16 PM, Joe wrote: On Tue, 29 Mar 2022 14:36:55 -0400 Chuck Zmudzinski wrote: I do like synaptic also because it saves a history of all the changes that it makes to the system. The apt tools also do this, but in a more user-hostile way. See /var/log/apt/history.log. This may be what Synaptic uses, I'm never quite sure of the sharing between the apt tools. It looks to me like synaptic's history only logs the changes synaptic makes, while /var/log/apt/history.log logs changes made by any of the apt tools, including synaptic. Chuck
Re: Does this happen often with sid?
On 3/29/22 10:46 AM, Joe wrote: On Mon, 28 Mar 2022 17:54:23 -0400 Chuck Zmudzinski wrote: On 3/28/22 5:35 PM, Ash Joubert wrote: On 29/03/2022 03:34, Chuck Zmudzinski wrote: I am new to running the unstable sid distribution. Today I wanted to upgrade it and when using the dist-upgrade option of apt-get (I think that's equivalent to the full-upgrade option of apt), I got this: [...]> The problem is with the section that lists the packages that will be REMOVED. Yes, this is normal for sid. Unwanted removals are usually a sign that dependencies are in transition. All sid administrators should know how to recognise this situation and avoid unwanted removals. I use: apt-get -s -V -o Debug::pkgProblemResolver=yes dist-upgrade to simulate a dist-upgrade to see what is going on and then "apt-mark hold" to hold packages until I am satisfied that dist-upgrade can proceed without unwanted removals. I use the package web page, package tracker, and transition tracker <https://release.debian.org/transitions/> to help identify the cause. "apt-mark showhold" lists held packages, which can be unheld when the transition is complete. Kind regards, Thank you, Ash, for this tip as I learn how to manage package dependencies on Sid. I also look at the package web page and package trackers to see what might be wrong. I will continue to use stable most of the time for ordinary work, and keep Sid up to date when I am working on bug fixes. It looks like quite a few packages are currently affected by the recent upgrade of Python to 3.10, including Xen, Samba, and Libre Office. For Xen, it appears a binary-only upload fixes it, and that was already done earlier today. A couple of other remarks: aptitude uses a more sophisticated algorithm to decide upgrades. Some sets of upgrades require to be done in a specific order, and aptitude is better able to find such cases. Don't try it with several hundred packages though, it will take forever. For example, apt on my sid is currently leaving about 100 packages untouched, and aptitude upgraded 20 of them. It's never going to get everything, but it may just manage that one critical package that you absolutely must get upgraded. If you have plenty of time, you can try it by hand. It is possible to do this with any of the tools, but I'm most comfortable with Synaptic. I did once clear a logjam completely by patient use of Synaptic, every single withheld package could be upgraded if it was done in the right order, but this is extremely rare. Almost always, as has been said, there are dependency issues that order of upgrade does not affect. One other point: don't leave sid for too long without maintenance. I upgrade mine most days, but I'd recommend not leaving it longer than a couple of weeks when times are busy. Sid goes relatively quiet during the release freeze, when nothing new can be moved out to testing, but it gets fairly frantic just after the release. I would suggest upgrading at least once a week then. Thank you Joe for your suggestions about managing package dependencies in Sid. I did not know that aptitude uses a different algorithm for calculating the upgrade, and it is good to know that I can try it instead of apt or apt-get. I do like synaptic also because it saves a history of all the changes that it makes to the system. I realize Sid needs at least weekly maintenance. That's a valid point also. Regards, Chuck
Re: Does this happen often with sid?
On 3/28/22 3:04 PM, songbird wrote: ... running unstable there's a few mailing lists i'd follow (release, devel and boot), ctte is also worth it for seeing what issues people are hitting that haven't had an easy answer yet. transition tracker too. Thanks, I will have a look at those places when there are issues. currently the python 3.10 transition is being worked on so that may take some time to sort through. i don't really follow sid/unstable as that is a bit too choatic for me. testing is close enough for my interests and a few selected packages and the most recent kernels are about where i end up. :) songbird I am now running Sid mainly to try to fix a bug in Xen upstream, and the newer the version of Xen I test on, the better. All the best, Chuck
Re: Does this happen often with sid?
On 3/28/22 5:35 PM, Ash Joubert wrote: On 29/03/2022 03:34, Chuck Zmudzinski wrote: I am new to running the unstable sid distribution. Today I wanted to upgrade it and when using the dist-upgrade option of apt-get (I think that's equivalent to the full-upgrade option of apt), I got this: [...]> The problem is with the section that lists the packages that will be REMOVED. Yes, this is normal for sid. Unwanted removals are usually a sign that dependencies are in transition. All sid administrators should know how to recognise this situation and avoid unwanted removals. I use: apt-get -s -V -o Debug::pkgProblemResolver=yes dist-upgrade to simulate a dist-upgrade to see what is going on and then "apt-mark hold" to hold packages until I am satisfied that dist-upgrade can proceed without unwanted removals. I use the package web page, package tracker, and transition tracker <https://release.debian.org/transitions/> to help identify the cause. "apt-mark showhold" lists held packages, which can be unheld when the transition is complete. Kind regards, Thank you, Ash, for this tip as I learn how to manage package dependencies on Sid. I also look at the package web page and package trackers to see what might be wrong. I will continue to use stable most of the time for ordinary work, and keep Sid up to date when I am working on bug fixes. It looks like quite a few packages are currently affected by the recent upgrade of Python to 3.10, including Xen, Samba, and Libre Office. For Xen, it appears a binary-only upload fixes it, and that was already done earlier today. Cheers, Chuck
Re: Does this happen often with sid?
On 3/28/22 10:52 AM, Andrew M.A. Cater wrote: On Mon, Mar 28, 2022 at 10:34:01AM -0400, Chuck Zmudzinski wrote: The problem is with the section that lists the packages that will be REMOVED. It looks like the upgrade to the python3 packages that remove/replace some existing python3 packages versions triggers apt to also remove samba and xen-utils-4.16, which I do not want, so I aborted it. Can I expect that in due time, the python3 dependencies will be updated so the full upgrade can succeed without removing the xen-utils-4.16 and samba packages? Thanks, Chuck Hi Chuck, Yes, this is entirely normal in Sid and is the main reason that we discourage people in general from running it as a distribution: if it breaks, you get to keep both pieces and are expected to be able to fix missing dependencies. In this instance, I suspect that samba will be fixed relatively quickly - I'm honestly not sure how big the Xen team is at the moment. It looks like the cause of the problem is an upgrade to Python 3.10 and it is also looks like it is already fixed for Xen by the Build Daemon according to this changelog entry for today's upload of Xen packages to the main archive: xen (4.16.0+51-g0941d6cb-1+b1) sid; urgency=low, binary-only=yes * Binary-only non-maintainer upload for amd64; no source changes. * Python 3.10 as default -- amd64 / i386 Build Daemon (x86-ubc-01) Mon, 28 Mar 2022 11:29:11 + I am still waiting for the fix for samba, though. Also, on my desktop Sid installation with libreoffice, the Python 3.10 upgrade also removes libreoffice until that dependency is fixed for libreoffice. So it looks like the Python 3.10 upgrade is going to cause some packages to be removed with the full-upgrade option to apt, so be careful out there upgrading Sid today. Cheers, Chuck
Re: Does this happen often with sid?
On 3/28/2022 10:52 AM, Andrew M.A. Cater wrote: On Mon, Mar 28, 2022 at 10:34:01AM -0400, Chuck Zmudzinski wrote: I am new to running the unstable sid distribution. Today I wanted to upgrade it and when using the dist-upgrade option of apt-get (I think that's equivalent to the full-upgrade option of apt), I got this: -- user@debian:~$ sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: attr grub-xen-bin grub-xen-host libcephfs2 libldap-2.4-2 libldb2 libpython3.9 libpython3.9-minimal libpython3.9-stdlib libtdb1 libyaml-0-2 linux-image-5.16.0-3-amd64 python3-dnspython python3-gpg python3-importlib-metadata python3-markdown python3-more-itertools python3-pygments python3-requests-toolbelt python3-yaml python3-zipp python3.9 python3.9-minimal samba-common tdb-tools xen-hypervisor-4.16-amd64 xen-hypervisor-common xen-utils-common xenstore-utils Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: python3-ldb python3-samba python3-talloc python3-tdb samba samba-common-bin samba-dsdb-modules samba-libs samba-vfs-modules xen-system-amd64 xen-utils-4.16 The following NEW packages will be installed: libpython3.10-minimal libpython3.10-stdlib python3-charset-normalizer python3.10 python3.10-minimal The following packages will be upgraded: dirmngr gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm libpython3-stdlib python3 python3-minimal python3-requests 11 upgraded, 5 newly installed, 11 to remove and 0 not upgraded. Need to get 9,842 kB of archives. After this operation, 76.2 MB disk space will be freed. Do you want to continue? [Y/n] n Abort. user@debian:~$ The problem is with the section that lists the packages that will be REMOVED. It looks like the upgrade to the python3 packages that remove/replace some existing python3 packages versions triggers apt to also remove samba and xen-utils-4.16, which I do not want, so I aborted it. Can I expect that in due time, the python3 dependencies will be updated so the full upgrade can succeed without removing the xen-utils-4.16 and samba packages? Thanks, Chuck Hi Chuck, [The xscreensaver person, I presume - \o/ ] Yes, this is entirely normal in Sid and is the main reason that we discourage people in general from running it as a distribution: if it breaks, you get to keep both pieces and are expected to be able to fix missing dependencies. In this instance, I suspect that samba will be fixed relatively quickly - I'm honestly not sure how big the Xen team is at the moment. There's every likelihood that it will gradually be fixed as things move forwards but this is Sid so there's no guarantee that it won't break elsewhere in some new and interesting way. All the very best, as ever, Andy Cater Thanks, Andy, that seems reasonable. I will try to help the Xen team with this if I can. I have been in contact with them a bit in the past. Chuck
Does this happen often with sid?
I am new to running the unstable sid distribution. Today I wanted to upgrade it and when using the dist-upgrade option of apt-get (I think that's equivalent to the full-upgrade option of apt), I got this: -- user@debian:~$ sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: attr grub-xen-bin grub-xen-host libcephfs2 libldap-2.4-2 libldb2 libpython3.9 libpython3.9-minimal libpython3.9-stdlib libtdb1 libyaml-0-2 linux-image-5.16.0-3-amd64 python3-dnspython python3-gpg python3-importlib-metadata python3-markdown python3-more-itertools python3-pygments python3-requests-toolbelt python3-yaml python3-zipp python3.9 python3.9-minimal samba-common tdb-tools xen-hypervisor-4.16-amd64 xen-hypervisor-common xen-utils-common xenstore-utils Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: python3-ldb python3-samba python3-talloc python3-tdb samba samba-common-bin samba-dsdb-modules samba-libs samba-vfs-modules xen-system-amd64 xen-utils-4.16 The following NEW packages will be installed: libpython3.10-minimal libpython3.10-stdlib python3-charset-normalizer python3.10 python3.10-minimal The following packages will be upgraded: dirmngr gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm libpython3-stdlib python3 python3-minimal python3-requests 11 upgraded, 5 newly installed, 11 to remove and 0 not upgraded. Need to get 9,842 kB of archives. After this operation, 76.2 MB disk space will be freed. Do you want to continue? [Y/n] n Abort. user@debian:~$ The problem is with the section that lists the packages that will be REMOVED. It looks like the upgrade to the python3 packages that remove/replace some existing python3 packages versions triggers apt to also remove samba and xen-utils-4.16, which I do not want, so I aborted it. Can I expect that in due time, the python3 dependencies will be updated so the full upgrade can succeed without removing the xen-utils-4.16 and samba packages? Thanks, Chuck
Re: Definitive instructions for Buster LTS security updates
On 2/21/2022 10:28 AM, Christian Britz wrote: On 2022-02-21 15:45 UTC+0100, David Wright wrote: AFAICT, running buster, nothing has yet changed. My sources.list is attached (ignore the first line), and as of this morning it yields: And I think nothing will change in the future. Take the Stretch example at https://wiki.debian.org/LTS/Using. The sources.list stayed the same. Maybe buster-updates will disappear, I do not know how this is handled. IMO it makes totally sense to leave this unchanged - every system will automatically benefit from LTS. I also experienced the same behavior with Jessie and now with Stretch. I did not need to change anything in sources.list, and I received the LTS updates for Jessie and I still receive them for Stretch while it is still getting LTS updates. So I would expect buster to also not need any changes to sources.list to receive LTS updates. Regards, Chuck Zmudzinski
Re: Cannot login to my user?
Dear Thomas, If you can login as Bob on the command line, try journalctl --user and look for some error from your last login attempt to the gnome desktop. If you cannot login on the command line as Bob, try sudo journalctl after logging in as Sally and look for some error from your last login attempt as Bob. Regards, Chuck On 2/18/2022 12:36 PM, Christian Britz wrote: Mr. Anderson, can you login to the command line? If so, you could check the file .xsession-errors in your home directory. You can also switch with "Bob" to Xfce for testing purposes. If you can't resolve it, backup your data from /home/bob and empty the directory (start with a clean profile). Regards, Christian On 2022-02-18 18:15 UTC+0100, Thomas Anderson wrote: Hello Friends, I have Debian 9, I know I need to upgrade my dist, will do that tonight or tomorrow =) Last week, I made a new user say "Sally." Previously, for years, my main user "Bob" was running perfectly with a gnome desktop. Recently, I realized, I cannot login to Bob anymore?!? The login screen loads as expect, i type in my credentials for Bob, the screen goes black, then I end up at the login screen again?!? Sally can login. Sally happens to have a Xfce. I checked that there were no root owned files on Bob. There are none, since I read that could be a cause. Is there a log file I can check for login errors? Thanks
Re: Misremembered (was: Re: Stupid question)
On 2/14/2022 10:19 AM, Bijan Soleymani wrote: On 2022-02-14 10:02, rhkra...@gmail.com wrote: I think I did mis-remember this, and the behavior I described is more like the behavior of the Debian installer (i.e., it boots an image (with a Linux kernel) into RAM to use temporarily for the installation. AFAIK a ramdisk image is not only loaded when using the Debian installer, it is also loaded when booting a full installation on a disk. For example, the initrd.img-5.10.0-11-amd64 file that is created when installing a kernel and installed under /boot on bullseye systems contains the compressed contents of a filesystem that is loaded into RAM upon initial boot, and AFAIK that filesystem does not contain a kernel but it does contain kernel modules that are binary-compatible with the running kernel to support the proper initialization of various hardware. The main job of that initrd environment is to find and mount the installed root filesystem that is usually on an SSD these days. I just wanted to try to correct this for posterity. If anyone can confirm this (both my mistake about grub and my (new) recollection about the Debian installer, those would be good things.:-) Sorry for the noise! IMHO it's not noise if you are trying to clarify or correct something. Not sure about the Debian installer (except that it does boot and run Linux, but not sure it ever switches to another kernel midway), but the Grub bootloader is kind of a mini-OS, in that it can read files from filesystems (rather than some other bootloaders that read from specific sectors/blocks of a disk). Which is to say if you boot to grub and you are in the grub menu and see there is no entry for the particular kernel (or OS) you want, you can edit the boot parameters for any menu entry you see and boot the missing kernel (or OS) from then and there. (with other bootloaders you'd have to boot to the OS or boot from a live CD to modify the boot loader parameters). Also, grub has its own shell, and sometimes if something is not configured right, grub may drop into its shell where a knowledgeable user can type in commands such as the ls command to list files on the disks attached to the system and the configfile command which can be used to load the grub configuration if for some reason grub was unable to find the grub.cfg file that tells grub how to boot the system. This is a useful feature for those who know how to use it, and it has saved me from having to reinstall on more that one occasion. Chuck
Re: Stupid question
On 2/13/2022 11:23 AM, Andrei POPESCU wrote: On Du, 13 feb 22, 02:40:27, Chuck Zmudzinski wrote: This is my understanding of how grub works. It looks you are using the old MBR partitioning scheme. The logical partition indicates that. So I also assume you are using the legacy booting (not UEFI). So the first thing that happens is that you will have an active partition set that your BIOS will boot (if you have standard bootcode installed in the first sector of the disk). Legacy BIOS doesn't have an understanding of partitions, it will just look for a bootloader in the MBR of the mass storage device chosen to boot from. The active / bootable flag was (still is?) a Microsoft thing[1], Linux bootloaders never cared about it and can load operating systems regardless if the corresponding partition is marked active or not. [1] as far as I recall it was used in DOS times to let the bootloader know which is the system partition, but it could be (ab)used for multi-booting ;) Kind regards, Andrei That's a good clarification that the active partition is a Microsoft thing implemented by the bootcode Microsoft installs in the MBR of the device chosen to boot from. Now for an unanswered question: What does bootcode installed by Debian Linux in the MBR do? How does it decide which partition to boot from? I think this is what the OP is asking. Regards, Chuck
Re: Stupid question
On 2/12/2022 4:04 AM, Hans wrote: Dear list, I am thinking of a solution of a problem. But I have an understanding problem, maybe you can give some background knowledge. The problem: I have one harddrive, there are two linuces installed. The partitions are as followed: kali-linux: 1st primary -> /boot 2nd > / debian3rd primary -> /boot 4th logical > / > swap > /home (encrypted) > /usr (encrypted) > /var (encrypted) This is the structure, and as said before, only ONE drive. Now my question: Is it possible to configure grub that way, that I can choose either kali or debian to boot? What I might to know, please correct me: Both are running different kernels. As far as I understood grub, I can set the root partition ( / ) with the UUID. This is an entry in grub.cfg and maybe in /etc/default/grub. But how can I tell grub, to use the kernel of the second /boot? I dunno, if it is possible at all, to get a dual boot, the way I want it. With a combination of Windows + Linux on one harddrive this is working, however, just because grub does not touch the windows bootloader (as fas as I know), and what of course is also working, if you got two harddrives, each with different linux. They all can be booted from one grub installation, of course. Maybe I could find a solution, if I would have fully understood how grub is working, and what it is doing. Any hints are welcome, and if this does never work at all, please drop me a line. Best regards Hans This is my understanding of how grub works. It looks you are using the old MBR partitioning scheme. The logical partition indicates that. So I also assume you are using the legacy booting (not UEFI). So the first thing that happens is that you will have an active partition set that your BIOS will boot (if you have standard bootcode installed in the first sector of the disk). The active partition is either 1st primary in which case you will boot from the grub from kali, or 3rd primary in which case you will boot the grub from Debian. So first you need to see which partition your BIOS boots. You can view or change the partitions and which one is the active boot partition using a disk partition tool such as fdisk. If you set Debian's grub on the 3rd partition as the active boot partition, you should be able to fairly easily display a menu to select either kali or Debian on the grub menu. You will need to make sure os-prober is enabled, it is enabled by default on bullseye and older, but I think in bookworm and sid you need to enable it by a setting in /etc/default/grub). The changelog for grub on bookworm and unstable has an entry to tell you how, I think. You also need to set the timeout to something (usually 5 or 10 seconds) to display the menu, and you can also set a default OS to boot in /etc/default/grub to handle the case when you do not select an OS before the timeout expires. After that, you just run sudo update-grub from your Debian system and then on the next reboot the grub menu should have entries for both kali and Debian. Cheers, Chuck
Re: Query
On 2/7/2022 4:36 PM, Greg Wooledge wrote: On Mon, Feb 07, 2022 at 04:31:51PM -0500, Chuck Zmudzinski wrote: On 2/7/2022 10:50 AM, William Lee Valentine wrote: I am wondering whether a current Debian distribution can be installed and run on an older Pentium III computer. (I have Debian 11.2 on a DVD.) The computer is Dell Dimension XPS T500: Intel Pentium III processor (Katnai) memory: 756 megabytes, running at 500 megahertz IDE disc drive: 60 gigabytes Debian partition: currently 42 gigabytes Debian 6.0: Squeeze Based on what others are saying, it looks like a typical modern Debian desktop environment such as Gnome or Plasma KDE will not work well with such an old system. I suggest you look for a Distro that is tailored for old hardware. Bah, silly. Just use a traditional window manager instead of a bloated Desktop Environment. Problem solved. Which windows manager for an extremely resource-limited system? Debian's wiki page on window managers lists more than 30 possibilities. Its not silly to take a look at a distro based on Debian that is tailored for low resources as a starting point to try and build a Debian 11.2 system that will work OK on a Pentium III with less than 1 GB of memory. Debian provides so many packages, and such distros like antiX can give one an idea about which packages to use when trying to build a Debian 11.2 system that will work well on an older system with such a small amount of memory and such an old CPU. But the *real* problem will come when they try to run a web browser. That's where the truly massive memory demand is. 756 MB is plenty of RAM for daily use of everything except a web browser. Yes, it will be important to try to find a web browser that is the least bloated as possible. Again, looking at the browser choices of distros tailored for old hardware can help build a Debian 11.2 system that will work well on old hardware. In any case, it will need to be a carefully crafted selection of Debian 11.2 packages to have a decent experience, and most definitely start with a small netinst installation with only the text console to start, and then build the GUI environment carefully from the ground up. Again, good luck to the OP in trying out Debian 11.2 on his system. Chuck
Re: Query
On 2/7/2022 10:50 AM, William Lee Valentine wrote: I am wondering whether a current Debian distribution can be installed and run on an older Pentium III computer. (I have Debian 11.2 on a DVD.) The computer is Dell Dimension XPS T500: Intel Pentium III processor (Katnai) memory: 756 megabytes, running at 500 megahertz IDE disc drive: 60 gigabytes Debian partition: currently 42 gigabytes Debian 6.0: Squeeze Based on what others are saying, it looks like a typical modern Debian desktop environment such as Gnome or Plasma KDE will not work well with such an old system. I suggest you look for a Distro that is tailored for old hardware. See, for example this page: https://itsfoss.com/lightweight-linux-beginners/ A quick look at the 16 distros would make me try antiX-19 first: http://download.tuxfamily.org/antix/docs-antiX-19/FAQ/index.html and https://antixlinux.com/blog/ It advertises support down to as low as Pentium II and uses Debian buster as the base. Perhaps a later version will be based on bullseye. Its 32-bit version does not need to use a pae kernel, and it is systemd free, and these are probably some of the hacks that are needed to keep such an old system working well with modern software. There are also antiX 21 packages, but the blog page does not advertise version 21 as a release, perhaps it is a development or beta version based on bullseye. Good luck, Chuck If I install Debian 11.2, will it run on this machine? Will it preserve the files and directories that I have on Squeeze? I am not subscribed to this mailing list. I would appreciate advices. -- William Lee Valentine
Re: XEN domU: Guest Rx stalled, unreachable
On 1/16/2022 7:16 AM, Felix Odenkirchen wrote: Dear all, I'm running a stock Debian SID vm on xen, hostname "vm-sid". Dom0 is on stock Debian Bullseye, hostname "bigiron-one". apt updating vm-sid packages on 2022-01-13 08:11:00 UTC rendered vm-sid unaccessible over network upon reboot. Updated packages: bsdutils bsdextrautils dbus eject initramfs-tools libblkid1 libc-bin libfdisk1 libnss-systemd libpam-systemd libpython3.9-minimal libpython3.9-stdlib libsmartcols1 libsystemd0 libudev1 libuuid1 mailcap man-db mount python3-pkg-resources python3.9 python3.9-minimal systemd systemd-sysv systemd-timesyncd udev util-linux log messages on dom0: 12:36:35 felix: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0 12:36:35 kernel: [2348158.091840] xenbr0: port 4(vif18.0) entered blocking state 12:36:35 kernel: [2348158.091846] xenbr0: port 4(vif18.0) entered disabled state 12:36:35 kernel: [2348158.091991] device vif18.0 entered promiscuous mode 12:36:35 felix: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0.11:58:39 12:37:14 kernel: [2348197.078134] vif vif-18-0 vif18.0: Guest Rx ready 12:37:14 kernel: [2348197.078164] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready 12:37:14 kernel: [2348197.078235] xenbr0: port 4(vif18.0) entered blocking state 12:37:14 kernel: [2348197.078238] xenbr0: port 4(vif18.0) entered forwarding state 12:38:49 kernel: [2348292.051684] vif vif-18-0 vif18.0: Guest Rx stalled 12:38:49 kernel: [2348292.051759] xenbr0: port 4(vif18.0) entered disabled state WORKAROUND: 1. Logging in on virtual console felix@bigiron-one:~$ sudo xl console 18 2. bringing interface up manually felix@vm-sid:~# sudo ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enX0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:16:3e:14:07:93 brd ff:ff:ff:ff:ff:ff felix@vm-sid:~# sudo ip link set enX0 up felix@vm-sid:~# sudo dhclient 3. log on dom0 12:41:24 kernel: [2348446.972241] vif vif-18-0 vif18.0: Guest Rx ready 12:41:24 kernel: [2348446.972304] xenbr0: port 4(vif18.0) entered blocking state 12:41:24 kernel: [2348446.972308] xenbr0: port 4(vif18.0) entered forwarding state 4. network running and stable I fail to see why SID domU stopped bringing up its network interface. Worked perfectly before. Another apt update && apt upgrade didn't remove the problem, so no package fix yet :-/ All the other domU (Bullseye and Bookworm vm's) are not affected and running fine, How can I determine the source of the problem on vm-sid, or the relevant package? Regards, Felix Hi Felix, It looks to me like a change in one of the systemd or udev packages in vm-sid is causing the trouble here. In my experience with Debian, the networking startup stuff is not so straightforward, but I do know that systemd and udev are the software components responsible for setting up the network and responding to networking events such as plugging in an ethernet cable or turning on wifi. So I would look in the changelogs of the systemd and udev packages that were updated and see if you can get a clue on what might have changed to break your networking startup configuration. For example, if your network is setup using /etc/network/interfaces and ifup at startup and the systemd configuration changed so that the ifup script that reads /etc/network/interfaces are no longer called correctly at startup, then your network interface would not be brought up automatically at startup. In my experience, once when I changed some packages the network interface name changed and that caused my network interface to not come up properly at startup. To fix it, I had to tweak the systemd configuration. All the best, Chuck
Re: Impossible to give "write" permission on a sub folder
Read the ntfs-3 man page.
Take a look at the man page for ntfs-3g, the section on
Access Handling and Security:
From the ntfs-3g man page:
Access Handling and Security
By default, files and directories are owned by the effective
user and group of the mounting process, and ev‐
erybody has full read, write, execution and directory browsing
permissions. You can also assign permissions
to a single user by using the uid and/or the gid options
together with the umask, or fmask and dmask options.
Doing so, Windows users have full access to the files created by
ntfs-3g.
But, by setting the permissions option, you can benefit from the
full ownership and permissions features as
defined by POSIX. Moreover, by defining a Windows-to-Linux
user mapping, the ownerships and permissions are
even applied to Windows users and conversely.
If ntfs-3g is set setuid-root then non-root users will be also
able to mount volumes.
You use the defaults option when mounting. I do not know how that
affects access and security for ntfs-3g. I would suggest either using
uid and gid options when mounting instead, or using the
usermapping file that maps Windows users to Debian users.
You need to check which user under Windows owns those folders, which Windows
users have write access to those folders, etc.
As mentioned in the man page, there is a way to map Windows users to
Debian 11 users using the default .NTFS-3G/UserMapping file or a
custom usermapping file with the usermapping mount option.
I used this feature a long time ago, and the format for the usermapping
file is documented in the ntfs-3g man page.
As is said at the beginning of this reply, read the ntfs-3g man page!
HTH,
Chuck
On 11/26/2021 3:29 AM, lists.deb...@netc.eu wrote:
Hello to all,
I have a dual boot PC with Windows 10 and Debian 11
This PC has 2 drives, one SSD that has both operating systems and a
HDD where I store all other files (documents, music, images, ...)
The goal is to share this HDD between Windows and Debian. To do it, I
added the following line to the fstab file:
UUID=ACB23705B236D414 /mnt/windows ntfs-3g defaults,umask=000
0 0
the folders lount without any problem to /mnt/windows, all with the
correct permission settings (rwx) :
$ ls -l /mnt/windows/
total 80
drwxrwxrwx 1 root root 4096 14 nov. 20:20 '$RECYCLE.BIN'
drwxrwxrwx 1 root root 4096 24 nov. 15:59 CloudStation
drwxrwxrwx 1 root root 4096 21 nov. 11:44 Documents
-rwxrwxrwx 1 root root 8192 25 juin 08:15 DumpStack.log.tmp
drwxrwxrwx 1 root root 4096 22 nov. 20:41 Images
drwxrwxrwx 1 root root 4096 24 nov. 11:53 Music
drwxrwxrwx 1 root root 8192 23 nov. 06:21 'System Volume Information'
drwxrwxrwx 1 root root 40960 21 nov. 22:22 Downloads
drwxrwxrwx 1 root root 4096 21 nov. 19:44 Videos
My problem is that in some sub folders, I'm not getting the write
("w") permission. For example on the "Documents" one:
$ ls -l /mnt/windows/Documents/
total 117
drwxrwxrwx 1 root root 16384 24 nov. 15:59 User1
-rwxrwxrwx 1 root root 0 26 nov. 2020 Default.rdp
-rwxrwxrwx 1 root root 432 11 mars 2021 desktop.ini
dr-xr-xr-x 1 root root 40960 24 nov. 15:59 User2
drwxrwxrwx 1 root root 16384 24 nov. 16:00 Public
drwxrwxrwx 1 root root 4096 24 nov. 15:59 User3
dr-xr-xr-x 1 root root 20480 21 nov. 12:05 Scan
-rwxrwxrwx 1 root root 18432 4 déc. 2016 Thumbs.db
drwxrwxrwx 1 root root 0 16 nov. 23:13 'Unified Remote'
Most of the folders are OK, but I ave User2 and San that doesn't have
the write ("w") permission...
Do you have any idea on whats going on?
Thanks in advance for all the help,
Berst regards,
Marc
Re: GUI browser in VNC
On 10/20/2021 4:01 PM, Chuck Zmudzinski wrote: On 10/20/2021 4:06 AM, Julius Hamilton wrote: Hey, I’d like to run a desktop in VNC and open GUI browsers like Firefox in it. I succeeded in setting up the VNC server but after installing Firefox, Chromium and Chrome I find they don’t open when I launch them. Is this because I am root user? Is it just because you should always run browsers as non-root? Thanks very much, Julius I use the tigervnc-standalone-server package for VNC access. It allows a VNC server to be run as a normal user. It works fine with firefox on my system. Set up the VNC password and the xstartup script in the $HOME/.vnc configuration directory. The package provides tools such as vncpasswd to help set it up, and you can set the xstartup script to start any installed desktop environment. I have used it with gnome, lxde, and lxqt and it works fine. I don't think the package provides encrypted connections, though, Actually, looking at the man pages for tigervncserver, there are options to provide encrypted connections using X509 certs or TLS. This would also presumably require the VNC viewer to support X509 or TLS security, but I have not tried it. After installing and configuring it, start the server as an ordinary user: $ vncserver -geometry 1024x768 You can adjust the geometry as desired and connect to it from any VNC viewer. Also, as normal (non-root) user, you stop it with: $ vncserver -kill :1 Cheers, Chuck
Re: GUI browser in VNC
On 10/20/2021 4:06 AM, Julius Hamilton wrote: Hey, I’d like to run a desktop in VNC and open GUI browsers like Firefox in it. I succeeded in setting up the VNC server but after installing Firefox, Chromium and Chrome I find they don’t open when I launch them. Is this because I am root user? Is it just because you should always run browsers as non-root? Thanks very much, Julius I use the tigervnc-standalone-server package for VNC access. It allows a VNC server to be run as a normal user. It works fine with firefox on my system. Set up the VNC password and the xstartup script in the $HOME/.vnc configuration directory. The package provides tools such as vncpasswd to help set it up, and you can set the xstartup script to start any installed desktop environment. I have used it with gnome, lxde, and lxqt and it works fine. I don't think the package provides encrypted connections, though, so I only use it on a trusted private network or with a VPN that provides security and encryption. After installing and configuring it, start the server as an ordinary user: $ vncserver -geometry 1024x768 You can adjust the geometry as desired and connect to it from any VNC viewer. I also use Xen and Xen's built-in VNC server also works fine with firefox in my experience - Xen's built-in VNC server allows access to Debian running in Xen unprivileged domains from any VNC viewer, but that is probably a niche use case. Cheers, Chuck
Fwd: Privacy and defamation of character on Debian public forums
On 9/28/2021 11:34 AM, Jonathan Dowland wrote: On Tue, Sep 28, 2021 at 07:10:08AM -0400, Chuck Zmudzinski wrote: As the original poster, I can say this hits the nail on the head. Most definitely, Andy Smith and others claim a right to call newcomers like me a laughingstock, damned, etc., on the basis of their supposed god-like status. ... By overreaction, he clearly means I refused to worship him and his ilk as the gods they think they are, I think this is an unreasonable characterisation of Andy Smith which I invite you to retract. I've read all of his messages on this subject to this list (at least) and I thought he'd taken great pains to make clear that he was merely an interested bystander, no more important than anyone else -- including you! I agree to retract this. I am sure Andy Smith is a fine person, and I can see he devotes much of his time heping others use Debian, and that is a good thing that he does. My statement was an emotional overreaction in response to Borden, who clearly is overstating problems in Debian. I did too, and I am sorry. Thanks, Chuck
Re: Privacy and defamation of character on Debian public forums
On 9/28/2021 10:23 AM, Pierre-Elliott Bécue wrote: Chuck Zmudzinski wrote on 28/09/2021 at 13:10:08+0200: On 9/27/2021 9:18 PM, Borden wrote: I sympathise with your frustrations. The open source "community" - especially Debian - is not known for its civility. There have been numerous articles (and backlashes) identifying the rampant misogyny, racism, arrogance, murder and general rudeness amongst its members and leaders. If you're expecting a well-governed organisation with a robust, even-handed and consistent method for handling problems, your princess is in another castle. Unfortunately, the old economic principle "You get what you pay for" applies. People who are good at what they do charge good rates and are in too high demand to deal with us plebs for free. As in any volunteer organisation, positions attract people with way too much free time and whose opinions of themselves (including their legal scholarship) exceeds their abilities. It's pretty tribal. I'm speaking very broadly here and not in reference to anybody in particular, but I have numerous incidents from the past 20 years in mind. Many newcomers to open source are encouraged to read Eric Raymond's "How to ask questions the smart way" which is a rambling manifesto that establishes the caste system of project managers at the top and newcomers at the bottom. Contributors are to be worshipped as gods, and we must be grateful to them when they down from Nirvana to educate us. As the original poster, I can say this hits the nail on the head. Most definitely, Andy Smith and others claim a right to call newcomers like me a laughingstock, damned, etc., on the basis of their supposed god-like status. The fact is, I solved my bug (#994899) and wanted to help the Debian project out. And as thanks I get called a laughingstock and that I would be "damning" myself further if I didn't stop my alleged "overreaction." By overreaction, he clearly means I refused to worship him and his ilk as the gods they think they are, even claiming the power and right to damn newcomers at will. Yet they are the ones unable to solve their bug (#991967). And they are the gods to be worshiped? Ha ha! I wouldn't pay any of them a dime to try to squash a software bug. I will just fix it myself. Debian is closing in on a million bugs. That's a lot, it takes about 97 new bugs per day over the 28-year life-span of the project to get to a number that high. And that is only the ones that are reported. I have seen many bugs in free software that I did not bother to report, and I am sure many others have as well. I am inclined to say that if the truth be told, the only bugs that matter are the ones that Google, Amazon, Microsoft, IBM, etc. want to get solved. I see many bugs are marked as patch available, yet the patch is never applied. My bug is marked as patch available. But I am not Google or Amazon. So I doubt my patch for my bug will ever make it into the distribution. Apparently I have committed the deadly sin of questioning the gods. If Debian wants to prove me wrong, then Debian should accept my patch into the distribution, or at least consider it and have the courtesy to tell me why they can't or won't accept the patch. If they do work with me to get a fix into the Debian software for my bug, then I will retract my statement that I believe only the bugs that are important to Debian are the ones giant multinational corporations want a fix for. Or, think of it this way. Maybe the big software companies plant bugs on purpose in free software (or worse, malware, ransomware, etc.) so most people have no choice but to pay them for their commercial products and security solutions, and it is not good for their bottom line if too many people can get a secure, bug-free product for free. Again, if Debian accepts my patch for my bug, then I would stand corrected. Hi Chuck, You really should consider stopping to reply and leave things as they are. Regards, -- PEB I agree, it's time to stop this thread, I am satisfied with things how they are. All the best, Chuck
Re: Privacy and defamation of character on Debian public forums
On 9/27/2021 9:18 PM, Borden wrote: I sympathise with your frustrations. The open source "community" - especially Debian - is not known for its civility. There have been numerous articles (and backlashes) identifying the rampant misogyny, racism, arrogance, murder and general rudeness amongst its members and leaders. If you're expecting a well-governed organisation with a robust, even-handed and consistent method for handling problems, your princess is in another castle. Unfortunately, the old economic principle "You get what you pay for" applies. People who are good at what they do charge good rates and are in too high demand to deal with us plebs for free. As in any volunteer organisation, positions attract people with way too much free time and whose opinions of themselves (including their legal scholarship) exceeds their abilities. It's pretty tribal. I'm speaking very broadly here and not in reference to anybody in particular, but I have numerous incidents from the past 20 years in mind. Many newcomers to open source are encouraged to read Eric Raymond's "How to ask questions the smart way" which is a rambling manifesto that establishes the caste system of project managers at the top and newcomers at the bottom. Contributors are to be worshipped as gods, and we must be grateful to them when they down from Nirvana to educate us. As the original poster, I can say this hits the nail on the head. Most definitely, Andy Smith and others claim a right to call newcomers like me a laughingstock, damned, etc., on the basis of their supposed god-like status. The fact is, I solved my bug (#994899) and wanted to help the Debian project out. And as thanks I get called a laughingstock and that I would be "damning" myself further if I didn't stop my alleged "overreaction." By overreaction, he clearly means I refused to worship him and his ilk as the gods they think they are, even claiming the power and right to damn newcomers at will. Yet they are the ones unable to solve their bug (#991967). And they are the gods to be worshiped? Ha ha! I wouldn't pay any of them a dime to try to squash a software bug. I will just fix it myself. Debian is closing in on a million bugs. That's a lot, it takes about 97 new bugs per day over the 28-year life-span of the project to get to a number that high. And that is only the ones that are reported. I have seen many bugs in free software that I did not bother to report, and I am sure many others have as well. I am inclined to say that if the truth be told, the only bugs that matter are the ones that Google, Amazon, Microsoft, IBM, etc. want to get solved. I see many bugs are marked as patch available, yet the patch is never applied. My bug is marked as patch available. But I am not Google or Amazon. So I doubt my patch for my bug will ever make it into the distribution. Apparently I have committed the deadly sin of questioning the gods. If Debian wants to prove me wrong, then Debian should accept my patch into the distribution, or at least consider it and have the courtesy to tell me why they can't or won't accept the patch. If they do work with me to get a fix into the Debian software for my bug, then I will retract my statement that I believe only the bugs that are important to Debian are the ones giant multinational corporations want a fix for. Or, think of it this way. Maybe the big software companies plant bugs on purpose in free software (or worse, malware, ransomware, etc.) so most people have no choice but to pay them for their commercial products and security solutions, and it is not good for their bottom line if too many people can get a secure, bug-free product for free. Again, if Debian accepts my patch for my bug, then I would stand corrected. Chuck
Re: Privacy and defamation of character on Debian public forums
On 9/26/2021 7:28 AM, Chuck Zmudzinski wrote: On 9/26/2021 7:18 AM, rhkra...@gmail.com wrote: On Saturday, September 25, 2021 12:58:44 PM Chuck Zmudzinski wrote: I am truly sorry, are there second chances in the Debian Community? I hope and trust so -- I've had to make use of them more than once ;-) ... That is why defamation is not the only issue to discuss here. The other is privacy and whether or not Debian volunteers can discuss matters privately or does every criticism we have about another person need to be expressed in the public forums? Things certainly can be discussed privately, but (1) not everyone immediately thinks of that under all circumstances. (And may either (2) consider the criticism (if it is that) to be so mild it doesn't require private discussion, or (3) is useful for the entire list, and thus useful to be public rather than private. (In that situation (3) (or (2)), it would be nice if it were discussed in private first as an extra element of courtesy, but see (1). Have a good day! May I add (4) not everyone immediately thinks (or agrees) that it is not good to just include a link without also posting the relevant text from that link. I think posting the link with a summary of other relevant information is sufficient. I respect that opinion of the poster of message #10 of my bug, but I don't think I must agree with it. Now I know that's what he expects, and I will try to remember that in future interactions with him. All the best, Chuck Also, other people might be offended if I posted the link and did what the author of #10 wanted me to do, also include the relevant text of the link. What effect does that have? Suppose someone reads the link and then comes back to my message and finds repeated what I already said in the link. He/she becomes annoyed that I wasted her/his time. When I was formulating my initial bug report, how was I supposed to know how the author of message #10 wanted me to create my bug report? Cheers, Chuck
Re: Privacy and defamation of character on Debian public forums
On 9/26/2021 7:18 AM, rhkra...@gmail.com wrote: On Saturday, September 25, 2021 12:58:44 PM Chuck Zmudzinski wrote: I am truly sorry, are there second chances in the Debian Community? I hope and trust so -- I've had to make use of them more than once ;-) ... That is why defamation is not the only issue to discuss here. The other is privacy and whether or not Debian volunteers can discuss matters privately or does every criticism we have about another person need to be expressed in the public forums? Things certainly can be discussed privately, but (1) not everyone immediately thinks of that under all circumstances. (And may either (2) consider the criticism (if it is that) to be so mild it doesn't require private discussion, or (3) is useful for the entire list, and thus useful to be public rather than private. (In that situation (3) (or (2)), it would be nice if it were discussed in private first as an extra element of courtesy, but see (1). Have a good day! May I add (4) not everyone immediately thinks (or agrees) that it is not good to just include a link without also posting the relevant text from that link. I think posting the link with a summary of other relevant information is sufficient. I respect that opinion of the poster of message #10 of my bug, but I don't think I must agree with it. Now I know that's what he expects, and I will try to remember that in future interactions with him. All the best, Chuck
Re: Privacy and defamation of character on Debian public forums
On 9/25/2021 10:02 AM, Andy Smith wrote: Hello, On Sat, Sep 25, 2021 at 09:06:34AM -0400, rhkra...@gmail.com wrote: On Friday, September 24, 2021 05:31:47 PM The Wanderer wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 - specifically. the first reply (comment 10). […] I've read over message #5, and without being a Debian developer or a user of Xen, aside from being a little longer / wordier than probably necessary, I don't see anything so objectionable about it. [ I am not a member of the Debian Xen team and haven't contributed anything to this particular bug, but I have followed it all as I have an interest in the team's work. ] It's not outrageously objectionable, it's just not a very good bug report with some *slightly* objectionable elements and background. This whole thing is pretty mundane and has been blown out of all proportion by Chuck failing to handle reasonable advice given by someone trying to help in good faith. I don't doubt at all that the advice in message #10 was given in good faith. I thought the author of #10's decision to rudely refuse to collaborate with me forever by saying "Bye" in a later message was also an overreaction to anything wrong I might have done. Also what would have remained with a very niche audience (people interested in Debian's Xen packages) has now been shown to a much wider audience as a consequence of Chuck bringing this to the attention of debian-user. To explain a bit more of the background, you'll see that Chuck referred to another bug in that bug log and a lot of other discussion took place there. Some of the things that are wrong with Chuck's bug are that Chuck criticised the Debian Xen team for including particular patches, and made some other factually incorrect statements, For example? and wrote in a style as if as if the situation were fully known about by the Debian Xen team while valiant users like Chuck are crushed underfoot. I admit the Debian Xen Team may not have been aware of the situation, and besides, I was more concerned that the Debian Release Team did not notice that patches from an unstable branch of the Xen upstream source made it into the Debian stable release. There is what I would call a "Debian patch" exploit attack surface exposed here to the authors of malware. THAT is a serious issue. The Xen Team's patches in question are perfectly acceptable in unstable and maybe in testing, but IMO, not in stable. In reality, the Debian Xen team didn't have good visibility of the issue and it's not yet been proven where exactly the bug lies. Even if it was shown to be in a patch that the team HAD taken on questionable basis, so what, we are all volunteers here, there is no need to berate people for their good faith efforts, I think its an overstatement to say I "berated" anyone in the bug report. You, however, judge me as "damned" and as a "laughingstock" in your first reply to my original post. That also is an overstatement of anything wrong I might have done, don't you think? we should expect bug reports to just focus on finding and fixing the bug not as someone's platform to deal out a blame narrative. Agreed. Basically it's not a big deal and could have easily been turned around; I felt #10 was a fairly gentle request to focus on the facts and make progress but to say the criticism was not received well would be an understatement! I am truly sorry, are there second chances in the Debian Community? For example, one of the "strongest" statements in #10 is "It's good that you filed this bug against the Debian Xen package […] way you went about it ... not so good." Chuck's response to that seems to have been to go about complaining in multiple unrelated locations of how he has been accused of being "not good". Note that he's morphed a statement of "your bug report was not done in a good way" into "someone in the Debian community told me I was not a good person; remove their slander or risk being sued". A dramatic misrepresentation of what actually happened. The rest of it is full of things like that. Are you trying to say now I am not a good person? Seems so to me. It could be partially understandable if #10 had simply said, "your bug report sucks," which believe me, I have seen and continue to see even from long standing Debian Developers. But Diederik did also take the time to give useful advice about HOW to move the situation forward, in fact that was the majority of the response. I really appreciate Diederik's input, my point was I would have preferred he contact me in private about any criticisms he had for me personally before criticizing the way I wrote my bug report in public. That is what I would have done if I wanted to criticize him. But he is the one who made the first criticism of a Debian volunteer in PUBLIC. So to defend myself, it had to also be in public. That is why defamation is not the only issue to discuss here. The other is privacy and whether or not Debian
Re: Privacy and defamation of character on Debian public forums
On 9/24/2021 8:04 AM, Brad Rogers wrote: On Fri, 24 Sep 2021 07:45:03 -0400 Chuck Zmudzinski wrote: Hello Chuck, happened to me, but I would not be surprised if in the U.S. eventually Debian will get sued unless it scrubs its website of some of the In the USA, Section 230 covers this; Debian can't be held liable for comments made by others using their systems. However, if Debian refuses to remove defamatory comments, perhaps Debian could be held liable if Debian refuses to remove comments at a person's request if the comments truly harm a person's good reputation and, for example, destroys a person's ability to get a job in software development, or anywhere else for that matter. Who would hire me if they read what is now being said about me by Andy Smith, et. al. on Debian's web pages. If Debian wants to be sure to avoid such a lawsuit, I think Debian should remove at least some comments to completely avoid legal liability. I am sure I could find a lawyer in the U.S. to try it if I wanted to. Cheers, Chuck
Re: Privacy and defamation of character on Debian public forums
On 9/24/2021 8:04 AM, Brad Rogers wrote: On Fri, 24 Sep 2021 07:45:03 -0400 Chuck Zmudzinski wrote: Hello Chuck, happened to me, but I would not be surprised if in the U.S. eventually Debian will get sued unless it scrubs its website of some of the In the USA, Section 230 covers this; Debian can't be held liable for comments made by others using their systems. I am already satisfied that Debian has officially offered to hear my side of the story and scrub the public facing web pages that legitmetely offend me. Debian won't be held liable in this case because Andy Smith et al who have accused me of being "damned" on the public forums do not officially speak for Debian. Cheers, Chuck
Re: Privacy and defamation of character on Debian public forums
On 9/24/2021 10:10 AM, Jonathan Carter wrote: Hi Chuck On 2021/09/24 13:45, Chuck Zmudzinski wrote: I was accused in public of wrongdoing on the Debian bug tracking system which is hosted on a public, Debian website in response to a bug report I made. Since Debian's policy is to keep everything on its website public, and I was told every message I send regarding Debian must be put on Debian's public forums, then how can I try and work out a disagreement with someone in private emails instead of needing to expose the dispute in public with all the negativity, slander, and defamation that might entail? I am willing to cooperate with anyone to help improve Debian software, but only if they agree to not accuse me in public of wrongdoing without first discussing the matter with me in a private email or other private forum. I am not interested in suing Debian for what happened to me, but I would not be surprised if in the U.S. eventually Debian will get sued unless it scrubs its website of some of the comments people make about each other on Debian public forums. You can (and we'd appreciate it if you would) contact the Debian Community team directly (which would not be public) at: commun...@debian.org Please include the details like the relevant bug numbers and as much other detail as possible. thanks, -Jonathan It is Bug #994899, I ask that you remove every message except for my original bug report from the public facing servers. I leave it to the package maintainers to decide things like bug severity, etc. I think it is clear from why I want this if you read the whole bug report. Please read the bug report with all its messages, and I was especially upset that I was accused of being "not good" = bad, and just plain "wrong," and "ranting," etc. If you have any more questions, please reply to me privately and off-list. Also read the message Andy Smith posted in response to my post on the debian-user mailing list: https://lists.debian.org/debian-user/2021/09/msg00790.html I do not ask you to remove that message unless you think you should, but I cite it as evidence that there is a problem within the Debian community about not observing just plain common decency and respect for other persons. Thank you, Chuck Zmudzinski
Re: Privacy and defamation of character on Debian public forums
On 9/24/2021 9:19 AM, Andy Smith wrote: On Fri, Sep 24, 2021 at 07:45:03AM -0400, Chuck Zmudzinski wrote: I was accused in public of wrongdoing on the Debian bug tracking system That is an interesting point of view, but I think you were simply accused of being factually wrong and creating a poor quality bug report. It was your choice to take that extremely personally. how can I try and work out a disagreement with someone in private emails instead of needing to expose the dispute in public with all the negativity, slander, and defamation that might entail? You were not asked to continue a disagreement in public, you were asked to provide several pieces of factual information about your setup and experience so that you could be helped. My advice is to do that and only that. I see that you already started doing it, but you still could not resist surrounding that with large amounts of extraneous emotive text. And now it's leaked onto debian-user. Just write facts in the bug report that are relevant to the bug and not he-said she-said he did this to me, they lied about this. blah blah. If you can't, then just stop, as you already suggested you would. I am willing to cooperate with anyone to help improve Debian software, but only if they agree to not accuse me in public of wrongdoing without first discussing the matter with me in a private email or other private forum. You may be surprised to find that you get no takers for your "allow me to rant in your ear but you must never disagree with me" collaboration style. I am not interested in suing Debian for what happened to me, but I would not be surprised if in the U.S. eventually Debian will get sued unless it scrubs its website of some of the comments people make about each other on Debian public forums. Debian doesn't exist as a US entity, so good luck with that. Even writing about theoretically suing Debian because you can't write a coherent bug report makes you look like the worst kind of Internet laughing stock. Thoughts? I followed the bug you reported and thought that Diederik's response to you was exactly on the mark. I also was in the IRC channel where Diederik spent considerable time asking other developers questions just so that Diederik could help solve your bug report. I feel very sorry for Diederik that this effort was spent only to get this sort of tantrum from you. That you interpreted Diederik's advice as an attack I think says more about you than anything else and I recommend that you stop this overreaction now before you leave even more of a damning impression of yourself. After seeing what you have put Diederik through I would have absolutely no desire to spend effort helping you on a future problem and I think that is likely to be the view of others also. This behaviour is not helping your cause. I have no "cause" I am pursuing. I submitting the bug report to help make Debian better. It does not reflect well on the Debian community if this is the way it treats someone who tries to help. All the best, Chuck
Re: Privacy and defamation of character on Debian public forums
On 9/24/2021 9:19 AM, Andy Smith wrote: On Fri, Sep 24, 2021 at 07:45:03AM -0400, Chuck Zmudzinski wrote: I was accused in public of wrongdoing on the Debian bug tracking system That is an interesting point of view, but I think you were simply accused of being factually wrong and creating a poor quality bug report. It was your choice to take that extremely personally. how can I try and work out a disagreement with someone in private emails instead of needing to expose the dispute in public with all the negativity, slander, and defamation that might entail? You were not asked to continue a disagreement in public, you were asked to provide several pieces of factual information about your setup and experience so that you could be helped. My advice is to do that and only that. I see that you already started doing it, but you still could not resist surrounding that with large amounts of extraneous emotive text. And now it's leaked onto debian-user. Just write facts in the bug report that are relevant to the bug and not he-said she-said he did this to me, they lied about this. blah blah. If you can't, then just stop, as you already suggested you would. I am willing to cooperate with anyone to help improve Debian software, but only if they agree to not accuse me in public of wrongdoing without first discussing the matter with me in a private email or other private forum. You may be surprised to find that you get no takers for your "allow me to rant in your ear but you must never disagree with me" collaboration style. I am not interested in suing Debian for what happened to me, but I would not be surprised if in the U.S. eventually Debian will get sued unless it scrubs its website of some of the comments people make about each other on Debian public forums. Debian doesn't exist as a US entity, so good luck with that. Even writing about theoretically suing Debian because you can't write a coherent bug report makes you look like the worst kind of Internet laughing stock. Thoughts? I followed the bug you reported and thought that Diederik's response to you was exactly on the mark. I also was in the IRC channel where Diederik spent considerable time asking other developers questions just so that Diederik could help solve your bug report. I feel very sorry for Diederik that this effort was spent only to get this sort of tantrum from you. That you interpreted Diederik's advice as an attack I think says more about you than anything else and I recommend that you stop this overreaction now before you leave even more of a damning impression of yourself. After seeing what you have put Diederik through I would have absolutely no desire to spend effort helping you on a future problem and I think that is likely to be the view of others also. This behaviour is not helping your cause. Regards, Andy In your opinion, I am "damned." I sure am glad you are not God. All the best, Chuck
Privacy and defamation of character on Debian public forums
I was accused in public of wrongdoing on the Debian bug tracking system which is hosted on a public, Debian website in response to a bug report I made. Since Debian's policy is to keep everything on its website public, and I was told every message I send regarding Debian must be put on Debian's public forums, then how can I try and work out a disagreement with someone in private emails instead of needing to expose the dispute in public with all the negativity, slander, and defamation that might entail? I am willing to cooperate with anyone to help improve Debian software, but only if they agree to not accuse me in public of wrongdoing without first discussing the matter with me in a private email or other private forum. I am not interested in suing Debian for what happened to me, but I would not be surprised if in the U.S. eventually Debian will get sued unless it scrubs its website of some of the comments people make about each other on Debian public forums. Thoughts?
Re: Debian 11 installer crashed and reboot
On 8/24/2021 2:51 AM, Thomas Schmitt wrote: Hi, Chuck Zmudzinski wrote: I don't know when an official fix will come , but I have come up with a workaround that works for me: Congrats. Great investigation work, as far as i can judge as bystander. So it's only the initrd and not the kernel which spoils booting. (I wonder whether Secure Boot would detect and refuse on a manipulated kernel or initrd.) Have a nice day :) Thomas I suppose secure boot might fail but I am not using it in my Xen HVM. I think the kernel and initrd would need to be digitally signed for secure boot to be able to check them, and I think in Debian secure boot only the grub boot loader is digitally signed, and my hack does not change that. So it is possible Debian's secure boot would also work with my hack to the initrd. Cheers, Chuck
Re: Debian 11 installer crashed and reboot
On 8/19/2021 3:11 PM, Andy Smith wrote: Hi Chuck, On Tue, Aug 17, 2021 at 08:04:43AM -0400, Chuck Zmudzinski wrote: After some testing of the Debian 11 installer on Xen (using the debian-11.0.0-amd64-netinst.iso), I find that this image only supports installation into a Xen PV guest, the guest always crashes and reboots for either a BIOS or OVMF boot into an HVM Xen guest. Could you report this to Debian's Xen team as a bug? Perhaps it is as simple as needing different kernel options in the netinst installer kernel given that the full install works under HVM? The Debian Xen team is very under-resourced for human help and it has been a long time since they have managed to keep the version in stable to a recent and supported one upstream. If you run a Xen dom0 on Debian I think really you need to be building your own packages or using the Debian Xen team's packages from sid. The stable packaged 4.11 hypervisor is out of even security support upstream so it's not really suitable for production use. I don't think the Debian Xen team would recommend using it but would instead suggest using their newer package that;s in sid (on stable) and test/report bigs against that. But let's get this reported. I'm not skilled enough in Debian package building to help the team but I do still report bigs sometimes; for production use I am building packages from newer upstream source. For this problem I can't help as I don't run HVM guests (only PV and PVH). The Debian Xen team mailing list is at: https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xen-devel Cheers, Andy I just discovered this already has been reported as a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357 I don't know when an official fix will come , but I have come up with a workaround that works for me: This fix might also work on the live ISO images that are also reported to crash and reboot in Xen HVM domUs. Prerequisites: xorriso and initramfs-tools packages installed Download/copy debian-11.0.0-amd64-netinst.iso into current working directory: Step 1: Mount the original iso: mkdir CD sudo mount -o ro -t iso9660 debian-11.0.0-amd64-netinst.iso CD Step 2: Copy the initrd.gz file we need to modify: cp -p CD/install.amd/initrd.gz . Step 4: Unmount the original iso: sudo umount CD Step 5: As root, extract the initramfs into a working directory: sudo unmkinitramfs initrd.gz initramfs Step 6: As root, edit the start-udev script that causes the crash and reboot: sudo vi initramfs/lib/debian-installer/start-udev In the start-udev script change this line: udevadm trigger --action=add to dmesg | grep DMI: | grep 'Xen HVM domU' || udevadm trigger --action=add and save the file This change should only disable the udevadm trigger in Xen HVM DomUs. Step 7: Re-pack the initrd into a new initrd file: cd initramfs find . | sort | sudo cpio --reproducible --quiet -o -H newc > ../newinitrd cd .. gzip -v9f newinitrd Step 8: Create the new installation ISO: cp -p debian-11.0.0-amd64-netinst.iso debian-11.0.0-amd64-xenhvm-netinst.iso xorriso -dev debian-11.0.0-amd64-xenhvm-netinst.iso -boot_image any keep \ -map newinitrd.gz /install.amd/initrd.gz Optional Step 9: Clean up sudo rm -r initramfs newinitrd.gz initrd.gz The ISO image debian-11.0.0-amd64-xenhvm-netinst.iso can now be used to install Debian bullseye in a Xen HVM Domu. On the main menu, choose the Install option, not the graphical or expert options, in order to boot using the modified initrd.gz ramdisk. Cheers, Chuck Zmudzinski
Re: Debian 11 installer crashed and reboot
On 8/21/2021 7:06 PM, Chuck Zmudzinski wrote: On 8/21/2021 5:52 AM, Thomas Schmitt wrote: Hi, there might be an easier way (still depending on whether such simple file replacements are tolerated by the booting system): # Choose the desired new files new_kernel=...path.to.desired.new.kernel.in.some.mounted.filesystem... new_initrd=...path.to.desired.new.initrd.in.some.mounted.filesystem... # Choose the files in the ISO to be replaced by the new files. # The ISO needs not to be mounted. (Better it should not be mounted.) # Naively, i assume that it's about these two: old_kernel=/install.amd/xen/vmlinuz old_initrd=/install.amd/xen/initrd.gz # Copy netinst ISO to playground ISO cp debian-11.0.0-amd64-netinst.iso test.iso # Use xorriso multi-session to override the undesired files xorriso -dev test.iso \ -boot_image any keep \ -map "$new_kernel" "$old_kernel" \ -map "$new_initrd" "$old_initrd" This will result in a quite short run of xorriso, which will report something like ISO image produced: 8108 sectors Written to medium : 8288 sectors at LBA 193024 Writing to 'test.iso' completed successfully. (The numbers 8108 and 8288 are result of the sizes of the two dummy files which i used as $new_kernel #and new_initrd. Yours will be substantially larger due to the typical size of an initrd.) Inspection of the boot equipment of test.iso shows no differences, except the new storage position of the El Torito boot catalog and the enlarged ISO image size. When mounted by Linux, the paths /mnt/iso/install.amd/xen/vmlinuz /mnt/iso/install.amd/xen/initrd.gz lead to the content of $new_kernel and $new_initrd. Then it depends on the inner doings of boot loader and starting system, whether this perky change is tolerated. Have a nice day :) Thomas Hi Thomas, Thank you for these tips. I will use them to try to get a bullseye Debian installer ISO working in a Xen HVM DomU next week when I have some spare time and post the results here. All the best, Chuck This approach (using xorriso with -dev, -boot_image, and -map options) works to change the kernel and ramdisk on the ISO, and the new ISO does boot into a Xen HVM without crashing and rebooting, but I still have not succeeded in getiing the ramdisk configured correctly to boot the Debian installer. Using the ramdisk of a full install on the ISO causes init to drop to an initramfs shell because that ramdisk is not configured to start the Debian installer but instead expects a root filesystem to be passed to it on the linux kernel command line. I expect it is possible to create a ramdisk that will successfully boot the Debian installer in a Xen HVM. I think some components from the ramdisk of a full install are needed to prevent the crash and reboot, and it is a matter of identifying what components from the ramdisk of a full install are needed. I would suspect some kernel module that a Xen HVM needs is missing from the ramdisks on the installation ISO. I will continue to work on it this week in my spare time. Cheers, Chuck
Re: Debian 11 installer crashed and reboot
On 8/16/2021 2:30 AM, John Mok wrote: Hi all, Tried to install Debian 11 guest using netinst, but the installer crashed and reboot automatically. Host: Xen 4.11.4 on Debian 10 Guest: Debian 11 (kernel 5.10) Here is the steps to reproduce the problem:- 1) Either guest BIOS or OVMF boot 2) Select "Expert install" on installation menu Then, the guest crashed and reboot. Another try with the installer on Debian Live 11, it immediately crashed and reboot. Is it a installer bug or something ? Thanks a lot. John Mok This problem has been reported by Philip Susi on 2021-04-27 in a comment on linux kernel bug 207695: https://bugzilla.kernel.org/show_bug.cgi?id=207695#c3 The kernel panic is caused by the Xen virtual keyboard. I was able to capture a screenshot of the crash by setting panic=60 and removing quiet from the kernel command line on the grub menu (the kernel parameters for a grub boot entry can be adjusted by pressing e when that grub boot entry is highlighted, when booting with ovmf firmware). Error message reported by the kernel is: failed to write 'add' to '/devices/virtual/input/input2/uevent': cannot allocate memory This problem only occurs using the kernel on the installation media, a full-featured bullseye kernel boots fine in a Xen HVM guest. The installer bullseye kernel also boots fine from the installer media in a Xen PV guest. I think the Xen HVM virtual keyboard is one provided by Qemu. It apparently needs a larger buffer than the one provided by the installation kernel. Any ideas how to fix this in the installation kernel? Chuck
Re: Debian 11 installer crashed and reboot
On 8/21/2021 5:52 AM, Thomas Schmitt wrote: Hi, there might be an easier way (still depending on whether such simple file replacements are tolerated by the booting system): # Choose the desired new files new_kernel=...path.to.desired.new.kernel.in.some.mounted.filesystem... new_initrd=...path.to.desired.new.initrd.in.some.mounted.filesystem... # Choose the files in the ISO to be replaced by the new files. # The ISO needs not to be mounted. (Better it should not be mounted.) # Naively, i assume that it's about these two: old_kernel=/install.amd/xen/vmlinuz old_initrd=/install.amd/xen/initrd.gz # Copy netinst ISO to playground ISO cp debian-11.0.0-amd64-netinst.iso test.iso # Use xorriso multi-session to override the undesired files xorriso -dev test.iso \ -boot_image any keep \ -map "$new_kernel" "$old_kernel" \ -map "$new_initrd" "$old_initrd" This will result in a quite short run of xorriso, which will report something like ISO image produced: 8108 sectors Written to medium : 8288 sectors at LBA 193024 Writing to 'test.iso' completed successfully. (The numbers 8108 and 8288 are result of the sizes of the two dummy files which i used as $new_kernel #and new_initrd. Yours will be substantially larger due to the typical size of an initrd.) Inspection of the boot equipment of test.iso shows no differences, except the new storage position of the El Torito boot catalog and the enlarged ISO image size. When mounted by Linux, the paths /mnt/iso/install.amd/xen/vmlinuz /mnt/iso/install.amd/xen/initrd.gz lead to the content of $new_kernel and $new_initrd. Then it depends on the inner doings of boot loader and starting system, whether this perky change is tolerated. Have a nice day :) Thomas Hi Thomas, Thank you for these tips. I will use them to try to get a bullseye Debian installer ISO working in a Xen HVM DomU next week when I have some spare time and post the results here. All the best, Chuck
Re: Debian 11 installer crashed and reboot
On 8/19/2021 3:11 PM, Andy Smith wrote: Hi Chuck, On Tue, Aug 17, 2021 at 08:04:43AM -0400, Chuck Zmudzinski wrote: After some testing of the Debian 11 installer on Xen (using the debian-11.0.0-amd64-netinst.iso), I find that this image only supports installation into a Xen PV guest, the guest always crashes and reboots for either a BIOS or OVMF boot into an HVM Xen guest. Could you report this to Debian's Xen team as a bug? Perhaps it is as simple as needing different kernel options in the netinst installer kernel given that the full install works under HVM? Would you also consider the fact that the OP also noted that the live ISO also crashes and reboots in a Xen HVM guest a bug? My thought is that both netinst and live amd64 ISOs should work on a Xen HVM out of the box (OOTB). If I report a bug, I am inclined to consider the bug to be that both netinst and live amd64 ISOs crash in Xen HVM guests and the bug should not be closed until both ISOs work OOTB in a Xen HVM guest on both a default Xen/Dom0 stable and oldstable installation, so that users of oldstable can use oldstable to quickly and easily test stable in a Xen HVM guest. This would require, as I understand it, close cooperation between the Xen team, the Qemu team, and the Debian installer developers so those key parts of the Xen HVM environment play nicely together with the Debian installer. I also wonder if the bug should be reported to Debian installer developers instead of to the Xen team. Cheers, Chuck
Re: Debian 11 installer crashed and reboot
On 8/21/2021 4:34 AM, Thomas Schmitt wrote: Hi, John Mok wrote: As a quick fix on the make installer media work, how can I remake my own installation ISO by recompil ing the kernel and initramfs ? Chuck Zmudzinski wrote: A quick solution would not even require any recompilation of a kernel, since we know the kernel and ramdisk of an installed bullseye system does work in a Xen HVM guest. [...] I am not familiar with the process that the debian installer team uses to generate the installation ISOs, but if I wanted to learn I would start by looking at https://wiki.debian.org/DebianInstaller/CheckOut If there are no checksums in the ISO which would cover the initially booted kernel and the ramdisk, then you could also go the path of https://wiki.debian.org/RepackBootableISO This article mainly shows how to determine the necessary arguments for the ISO 9660 producing program. Nevertheless, in https://wiki.debian.org/RepackBootableISO#Methods_to_overwrite.2C_delete.2C_or_add_files it shows some ways how to do the desired manipulations of the ISO's file tree. I assume that questions about the entrails of a Debian installation ISO are best asked at debian-cd mailing list. (Although two of the experts there happen to be also our friendly list hosts here.) Have a nice day :) Thomas This is how it should be - I am happy that Debian installer developers are following the user list. There is no more important Debian user to support than the user who tries to install Debian for the first time. It is the Debian installer's job to try to ensure, as far as possible, that a new Debian user will be able to quickly and easily install Debian on all supported platforms. I presume that would include at least the bare hardware of the supported architectures, things like docker/Linux containers and supported virtual environments such as qemu/kvm and Xen. So the Debian installer developers should always monitor the Debian user lists for problems that users are having installing Debian in the supported computing environments. Cheers, Chuck
Re: Debian 11 installer crashed and reboot
On 8/21/2021 12:08 AM, Chuck Zmudzinski wrote: On 8/19/2021 3:11 PM, Andy Smith wrote: Hi Chuck, On Tue, Aug 17, 2021 at 08:04:43AM -0400, Chuck Zmudzinski wrote: After some testing of the Debian 11 installer on Xen (using the debian-11.0.0-amd64-netinst.iso), I find that this image only supports installation into a Xen PV guest, the guest always crashes and reboots for either a BIOS or OVMF boot into an HVM Xen guest. Could you report this to Debian's Xen team as a bug? Perhaps it is as simple as needing different kernel options in the netinst installer kernel given that the full install works under HVM? Hi Andy, That is exactly what I think the problem is. I will look into it and see if there is a simple solution like adding the correct kernel configuration options and kernel modules to the kernel and ramdisk on the default debian installer iso. The generic default amd64 iso should work in Xen HVM guests. The Debian Xen team is very under-resourced for human help and it has been a long time since they have managed to keep the version in stable to a recent and supported one upstream. If you run a Xen dom0 on Debian I think really you need to be building your own packages or using the Debian Xen team's packages from sid. The stable packaged 4.11 hypervisor is out of even security support upstream so it's not really suitable for production use. With bullseye released, that is oldstable now. Xen 4.14 is on bullseye and I think Xen 4.15 is the latest release upstream, so it is not too far behind now. I presume Xen 4.14 is still getting security patches upstream, but I cannot find a good explanation of Xen's support cycle on their website and I don't know if Debian can expect upstream to support 4.14 until bullseye becomes oldstable in two years or so. I found this page: https://xenbits.xen.org/docs/unstable/support-matrix.html Xen 4.14 will have security support until 2023-07-24, which should cover most of the time bullseye will be the stable version. Chuck I don't think the Debian Xen team would recommend using it but would instead suggest using their newer package that;s in sid (on stable) and test/report bigs against that. But let's get this reported. If/when I find the solution, I will post a bug report and see if the Xen team can get the solution into the installer media for future bullseye point releases. I already know the same problem exists on Xen 4.14 on bullseye, and AFAIK even sid has not bumped to 4.15 yet. I'm not skilled enough in Debian package building to help the team but I do still report bigs sometimes; for production use I am building packages from newer upstream source. For this problem I can't help as I don't run HVM guests (only PV and PVH). I always had difficulty with pygrub/pvgrub on PV domains, and using bullseye's Xen-4.14 version, I could not boot the debian installer iso with pygrub but had to extract the xen-enabled kernel and ramdisk to Dom0 and boot them from within Dom0. I think this is another Xen bug in the Xen-4.14 package that I also will investigate next week. Probably some tweaks to the pygrub script are needed there. I have always wanted to try out PVH domains, but have not done so yet. The Debian Xen team mailing list is at: https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xen-devel I will do some testing on this next week. I do want to help the Xen team make Debian more Xen-friendly and will report these bugs, hopefully sometime next week. Cheers, Chuck Cheers, Andy
Re: Debian 11 installer crashed and reboot
On 8/21/2021 12:42 AM, John Mok wrote: Hi Chuck, As a quick fix on the make installer media work, how can I remake my own installation ISO by recompil ing the kernel and initramfs ? Can give me some directions ? Not yet regarding what kernel options are needed, because I have not done any tests yet to see which kernel configuration options or modules might be missing that are needed by the Xen HVM. A quick solution would not even require any recompilation of a kernel, since we know the kernel and ramdisk of an installed bullseye system does work in a Xen HVM guest. Therefore... if you can build an iso that is the same as the installation iso in every way except that it boots using the default Debian kernel and ramdisk on the final installed system instead of the stripped down kernels/ramdisks on the installation media, you should get an iso that can boot the debian installer in a Xen HVM guest. I am not familiar with the process that the debian installer team uses to generate the installation ISOs, but if I wanted to learn I would start by looking at https://wiki.debian.org/DebianInstaller/CheckOut <https://wiki.debian.org/DebianInstaller/CheckOut> and follow the instructions in the wiki checkout the source code for the debian installer and from there you might be able to learn how to build and modify a Debian installation ISO. Regards, Chuck Chuck Thanks a lot. John Mok On Sat, Aug 21, 2021, 12:08 Chuck Zmudzinski <mailto:brchu...@netscape.net>> wrote: On 8/19/2021 3:11 PM, Andy Smith wrote: > Hi Chuck, > > On Tue, Aug 17, 2021 at 08:04:43AM -0400, Chuck Zmudzinski wrote: >> After some testing of the Debian 11 installer on Xen >> (using the debian-11.0.0-amd64-netinst.iso), I find that >> this image only supports installation into a Xen PV guest, >> the guest always crashes and reboots for either a BIOS >> or OVMF boot into an HVM Xen guest. > Could you report this to Debian's Xen team as a bug? Perhaps it is > as simple as needing different kernel options in the netinst > installer kernel given that the full install works under HVM? Hi Andy, That is exactly what I think the problem is. I will look into it and see if there is a simple solution like adding the correct kernel configuration options and kernel modules to the kernel and ramdisk on the default debian installer iso. The generic default amd64 iso should work in Xen HVM guests. > > The Debian Xen team is very under-resourced for human help and it > has been a long time since they have managed to keep the version in > stable to a recent and supported one upstream. If you run a Xen dom0 > on Debian I think really you need to be building your own packages > or using the Debian Xen team's packages from sid. > > The stable packaged 4.11 hypervisor is out of even security support > upstream so it's not really suitable for production use. With bullseye released, that is oldstable now. Xen 4.14 is on bullseye and I think Xen 4.15 is the latest release upstream, so it is not too far behind now. I presume Xen 4.14 is still getting security patches upstream, but I cannot find a good explanation of Xen's support cycle on their website and I don't know if Debian can expect upstream to support 4.14 until bullseye becomes oldstable in two years or so. > I don't > think the Debian Xen team would recommend using it but would instead > suggest using their newer package that;s in sid (on stable) and > test/report bigs against that. But let's get this reported. If/when I find the solution, I will post a bug report and see if the Xen team can get the solution into the installer media for future bullseye point releases. I already know the same problem exists on Xen 4.14 on bullseye, and AFAIK even sid has not bumped to 4.15 yet. > > I'm not skilled enough in Debian package building to help the team > but I do still report bigs sometimes; for production use I am > building packages from newer upstream source. > > For this problem I can't help as I don't run HVM guests (only PV and > PVH). I always had difficulty with pygrub/pvgrub on PV domains, and using bullseye's Xen-4.14 version, I could not boot the debian installer iso with pygrub but had to extract the xen-enabled kernel and ramdisk to Dom0 and boot them from within Dom0. I think this is another Xen bug in the Xen-4.14 package that I also will investigate next week. Probably some tweaks to the pygrub script are needed there. I have always wanted to try out PVH domains, but have not done so yet. > > The Debian Xen team mailing list is at: > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xe
Re: Debian 11 installer crashed and reboot
On 8/19/2021 3:11 PM, Andy Smith wrote: Hi Chuck, On Tue, Aug 17, 2021 at 08:04:43AM -0400, Chuck Zmudzinski wrote: After some testing of the Debian 11 installer on Xen (using the debian-11.0.0-amd64-netinst.iso), I find that this image only supports installation into a Xen PV guest, the guest always crashes and reboots for either a BIOS or OVMF boot into an HVM Xen guest. Could you report this to Debian's Xen team as a bug? Perhaps it is as simple as needing different kernel options in the netinst installer kernel given that the full install works under HVM? Hi Andy, That is exactly what I think the problem is. I will look into it and see if there is a simple solution like adding the correct kernel configuration options and kernel modules to the kernel and ramdisk on the default debian installer iso. The generic default amd64 iso should work in Xen HVM guests. The Debian Xen team is very under-resourced for human help and it has been a long time since they have managed to keep the version in stable to a recent and supported one upstream. If you run a Xen dom0 on Debian I think really you need to be building your own packages or using the Debian Xen team's packages from sid. The stable packaged 4.11 hypervisor is out of even security support upstream so it's not really suitable for production use. With bullseye released, that is oldstable now. Xen 4.14 is on bullseye and I think Xen 4.15 is the latest release upstream, so it is not too far behind now. I presume Xen 4.14 is still getting security patches upstream, but I cannot find a good explanation of Xen's support cycle on their website and I don't know if Debian can expect upstream to support 4.14 until bullseye becomes oldstable in two years or so. I don't think the Debian Xen team would recommend using it but would instead suggest using their newer package that;s in sid (on stable) and test/report bigs against that. But let's get this reported. If/when I find the solution, I will post a bug report and see if the Xen team can get the solution into the installer media for future bullseye point releases. I already know the same problem exists on Xen 4.14 on bullseye, and AFAIK even sid has not bumped to 4.15 yet. I'm not skilled enough in Debian package building to help the team but I do still report bigs sometimes; for production use I am building packages from newer upstream source. For this problem I can't help as I don't run HVM guests (only PV and PVH). I always had difficulty with pygrub/pvgrub on PV domains, and using bullseye's Xen-4.14 version, I could not boot the debian installer iso with pygrub but had to extract the xen-enabled kernel and ramdisk to Dom0 and boot them from within Dom0. I think this is another Xen bug in the Xen-4.14 package that I also will investigate next week. Probably some tweaks to the pygrub script are needed there. I have always wanted to try out PVH domains, but have not done so yet. The Debian Xen team mailing list is at: https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xen-devel I will do some testing on this next week. I do want to help the Xen team make Debian more Xen-friendly and will report these bugs, hopefully sometime next week. Cheers, Chuck Cheers, Andy
Re: Debian 11 installer crashed and reboot
On 8/17/2021 8:04 AM, Chuck Zmudzinski wrote: On 8/16/2021 4:25 AM, Andrew M.A. Cater wrote: On Mon, Aug 16, 2021 at 02:30:33PM +0800, John Mok wrote: Hi all, Tried to install Debian 11 guest using netinst, but the installer crashed and reboot automatically. Host: Xen 4.11.4 on Debian 10 Guest: Debian 11 (kernel 5.10) Here is the steps to reproduce the problem:- 1) Either guest BIOS or OVMF boot 2) Select "Expert install" on installation menu Then, the guest crashed and reboot. Another try with the installer on Debian Live 11, it immediately crashed and reboot. Is it a installer bug or something ? Thanks a lot. John Mok I think people would need many more details as to exactly what happens and when it reboots. So: You boot the installer - from just a .iso file / from the .iso flashed to a USB? Can you show what works and at what point it fails? The quick suggestion would be that it's something to do with Xen hypervisor but I'm not in any better position than to guess, since I don't use Xen here. I do know that none of the tests the media team do involve booting on Xen: in most cases we prefer to run on real hardware. Occasionally, some of the tests have to be run on KVM/QEMU. Xen as DomU is untested then. All the very best, as ever, Andy Cater After some testing of the Debian 11 installer on Xen (using the debian-11.0.0-amd64-netinst.iso), I find that this image only supports installation into a Xen PV guest, the guest always crashes and reboots for either a BIOS or OVMF boot into an HVM Xen guest. I also found that the device model fails to start if one tries to run the xen built-in vnc server for graphical output. The only solution is to connect to the Xen console using the xl console command. The -c switch to xl create did not work to connect to the Xen console when creating the guest; it could not find the pty device, so it is necessary to let the guest complete the startup and then run xl console to connect to the console once the VM is running. This will display the first page of the debian installer where the language is selected, and from there Debian 11 can be installed onto a virtual disk. The following lines in the xl.cfg file enabled the VM to boot the debian-11.0.0-amd64-netinst.iso as a PV Xen guest: bootloader = 'pygrub' bootloader_args= [ '--kernel=install.amd/xen/vmlinuz','--ramdisk=install.amd/xen/initrd.gz' ] I forgot one more essential tweak to get the VM to boot the Debian installer under pygrub and xen: It was necessary for the first disk to be the iso image, not the hard disk, in the disk = [ ... ] directive in the xl.cfg file when booting from the cd image. Otherwise, pygrub could not find the kernel and initrd images. This is documented somewhere, but I don't remember where, and the documentation for booting the debian installer into Xen is really not very good. Chuck Zmudzinski Once installed and booting from the virtual disk, the bootloader_args setting can be commented out. After booting from the virtual disk, the grub-pc package can be added to boot into a Xen HVM guest with BIOS booting, and if space is left for an efi partition, the grub-efi package can be installed to boot with OVMF after converting the partition table of the virtual disk from MBR to GPT. Also, the vnc server can be used for graphical output after booting from the virtual disk to run a desktop environment. All in all, it is a big pain to install Debian 11 on the Xen hypervisor using the debian installer, as it seems supporting Xen installations is not a priority for Debian. But once it is installed, it works very well on Xen, and I find I can use the same bullseye image to boot it as a Xen PV guest, a Xen HVM guest using BIOS boot, or as a Xen HVM guest using OVMF boot just by tweaking the xl.cfg configuration file after getting the image configured for such a setup. I can even boot the same image on the bare hardware by tweaking the initramfs-tools configuration in the installed bullseye image. Chuck Zmudzinski
Re: Debian 11 installer crashed and reboot
On 8/16/2021 4:25 AM, Andrew M.A. Cater wrote: On Mon, Aug 16, 2021 at 02:30:33PM +0800, John Mok wrote: Hi all, Tried to install Debian 11 guest using netinst, but the installer crashed and reboot automatically. Host: Xen 4.11.4 on Debian 10 Guest: Debian 11 (kernel 5.10) Here is the steps to reproduce the problem:- 1) Either guest BIOS or OVMF boot 2) Select "Expert install" on installation menu Then, the guest crashed and reboot. Another try with the installer on Debian Live 11, it immediately crashed and reboot. Is it a installer bug or something ? Thanks a lot. John Mok I think people would need many more details as to exactly what happens and when it reboots. So: You boot the installer - from just a .iso file / from the .iso flashed to a USB? Can you show what works and at what point it fails? The quick suggestion would be that it's something to do with Xen hypervisor but I'm not in any better position than to guess, since I don't use Xen here. I do know that none of the tests the media team do involve booting on Xen: in most cases we prefer to run on real hardware. Occasionally, some of the tests have to be run on KVM/QEMU. Xen as DomU is untested then. All the very best, as ever, Andy Cater After some testing of the Debian 11 installer on Xen (using the debian-11.0.0-amd64-netinst.iso), I find that this image only supports installation into a Xen PV guest, the guest always crashes and reboots for either a BIOS or OVMF boot into an HVM Xen guest. I also found that the device model fails to start if one tries to run the xen built-in vnc server for graphical output. The only solution is to connect to the Xen console using the xl console command. The -c switch to xl create did not work to connect to the Xen console when creating the guest; it could not find the pty device, so it is necessary to let the guest complete the startup and then run xl console to connect to the console once the VM is running. This will display the first page of the debian installer where the language is selected, and from there Debian 11 can be installed onto a virtual disk. The following lines in the xl.cfg file enabled the VM to boot the debian-11.0.0-amd64-netinst.iso as a PV Xen guest: bootloader = 'pygrub' bootloader_args= [ '--kernel=install.amd/xen/vmlinuz','--ramdisk=install.amd/xen/initrd.gz' ] Once installed and booting from the virtual disk, the bootloader_args setting can be commented out. After booting from the virtual disk, the grub-pc package can be added to boot into a Xen HVM guest with BIOS booting, and if space is left for an efi partition, the grub-efi package can be installed to boot with OVMF after converting the partition table of the virtual disk from MBR to GPT. Also, the vnc server can be used for graphical output after booting from the virtual disk to run a desktop environment. All in all, it is a big pain to install Debian 11 on the Xen hypervisor using the debian installer, as it seems supporting Xen installations is not a priority for Debian. But once it is installed, it works very well on Xen, and I find I can use the same bullseye image to boot it as a Xen PV guest, a Xen HVM guest using BIOS boot, or as a Xen HVM guest using OVMF boot just by tweaking the xl.cfg configuration file after getting the image configured for such a setup. I can even boot the same image on the bare hardware by tweaking the initramfs-tools configuration in the installed bullseye image. Chuck Zmudzinski
Re: Debian 11 installer crashed and reboot
On 8/16/2021 1:40 PM, Chuck Zmudzinski wrote: On 8/16/2021 12:49 PM, Chuck Zmudzinski wrote: On 8/16/2021 4:25 AM, Andrew M.A. Cater wrote: On Mon, Aug 16, 2021 at 02:30:33PM +0800, John Mok wrote: Hi all, Tried to install Debian 11 guest using netinst, but the installer crashed and reboot automatically. Host: Xen 4.11.4 on Debian 10 Guest: Debian 11 (kernel 5.10) Here is the steps to reproduce the problem:- 1) Either guest BIOS or OVMF boot 2) Select "Expert install" on installation menu Then, the guest crashed and reboot. Another try with the installer on Debian Live 11, it immediately crashed and reboot. Is it a installer bug or something ? Thanks a lot. John Mok I think people would need many more details as to exactly what happens and when it reboots. So: You boot the installer - from just a .iso file / from the .iso flashed to a USB? Can you show what works and at what point it fails? The quick suggestion would be that it's something to do with Xen hypervisor but I'm not in any better position than to guess, since I don't use Xen here. I do know that none of the tests the media team do involve booting on Xen: in most cases we prefer to run on real hardware. Occasionally, some of the tests have to be run on KVM/QEMU. Xen as DomU is untested then. All the very best, as ever, Andy Cater I can say bullseye runs fine as a Xen DomU on both the buster xen-4.11 hypervisor and the bullseye xen-4.14 hypervisor on my workstation, with either BIOS or OVMF boot, but mine is a bullseye image upgraded from buster several months ago. I have not tried the bullseye debian installer on the xen hypervisor. Maybe for installing bullseye on xen you can try installing buster first then upgrade it to bullseye if the debian bullseye installer does not work on the xen hypervisor. Chuck Zmudzinski I would also ask if you have successfully booted another linux distro (an earlier Debian or another distribution such as ubuntu) on your Debian 10 xen-4.11.4 hypervisor. If not, the problem may be with your xen configuration files on your Debian 10 host system, not with the Debian 11 installer. Maybe some tweaks to the DomU xl.cfg configuration file for your Debian 11 DomU or to the xen hypervisor boot options (usually set in /etc/default/grub) might get it working. Chuck Zmudzinski I tested the debian-11.0.0-amd64-netinst.iso image on my Debian 10 xen-4.11.4 hypervisor using both OVMF and BIOS boot using an HVM type Xen guest, and in both cases, I can confirm the same behavior as the OP: crash and restart after selecting any of the installation options from the grub menu that is displayed after booting. Nevertheless, a full installation of Debian 11 boots and runs fine in the same environment under Xen. Browsing the files in the iso image, I can see there is a folder for xen: /install.amd/xen with three files in it: vmlinuz, initrd.gz, and debian.cfg. However, these files in the xen folder are never referenced anywhere from the menu or submenu items in the /boot/grub/grub.cfg file on the iso image. So a workaround would be to create an iso image with a menu entry in the /boot/grub/grub.cfg file for an installation on xen, and that grub menu item would be configured to load the vmlinuz kernel and initrd.gz image in the /install.amd/xen directory. It might also be possible to escape to the grub command shell instead of selecting one of the installation options after booting and manually enter the commands to load the xen-enabled kernel and initrd.gz images in the /install.amd/xen folder on the netinst iso, but that is not very user friendly, and I am not even sure if those images are mainly for a PV type Xen guest rather that an HVM type Xen guest that really should not need a special kernel or initrd image, but I could be wrong about that. Also, the debian.cfg file in /install.amd/xen mentions the need to use an iso image that supports installation under xen, and it references things like multi-arch iso images which I don't think exist anymore in modern Debian. Anyway, I suggest the OP read this debian.cfg file and try using the suggestions there to get the debian 11 installer running under xen. To summarize, I do not think the Debian installer is designed for easy installation under Xen, and it is not clear exactly which iso is needed, nor is it clear which type of Xen guest should be configured (PV or HVM) to enable installation of Debian 11 under Xen. Chuck Zmudzinski
Re: Debian 11 installer crashed and reboot
On 8/16/2021 12:49 PM, Chuck Zmudzinski wrote: On 8/16/2021 4:25 AM, Andrew M.A. Cater wrote: On Mon, Aug 16, 2021 at 02:30:33PM +0800, John Mok wrote: Hi all, Tried to install Debian 11 guest using netinst, but the installer crashed and reboot automatically. Host: Xen 4.11.4 on Debian 10 Guest: Debian 11 (kernel 5.10) Here is the steps to reproduce the problem:- 1) Either guest BIOS or OVMF boot 2) Select "Expert install" on installation menu Then, the guest crashed and reboot. Another try with the installer on Debian Live 11, it immediately crashed and reboot. Is it a installer bug or something ? Thanks a lot. John Mok I think people would need many more details as to exactly what happens and when it reboots. So: You boot the installer - from just a .iso file / from the .iso flashed to a USB? Can you show what works and at what point it fails? The quick suggestion would be that it's something to do with Xen hypervisor but I'm not in any better position than to guess, since I don't use Xen here. I do know that none of the tests the media team do involve booting on Xen: in most cases we prefer to run on real hardware. Occasionally, some of the tests have to be run on KVM/QEMU. Xen as DomU is untested then. All the very best, as ever, Andy Cater I can say bullseye runs fine as a Xen DomU on both the buster xen-4.11 hypervisor and the bullseye xen-4.14 hypervisor on my workstation, with either BIOS or OVMF boot, but mine is a bullseye image upgraded from buster several months ago. I have not tried the bullseye debian installer on the xen hypervisor. Maybe for installing bullseye on xen you can try installing buster first then upgrade it to bullseye if the debian bullseye installer does not work on the xen hypervisor. Chuck Zmudzinski I would also ask if you have successfully booted another linux distro (an earlier Debian or another distribution such as ubuntu) on your Debian 10 xen-4.11.4 hypervisor. If not, the problem may be with your xen configuration files on your Debian 10 host system, not with the Debian 11 installer. Maybe some tweaks to the DomU xl.cfg configuration file for your Debian 11 DomU or to the xen hypervisor boot options (usually set in /etc/default/grub) might get it working. Chuck Zmudzinski
Re: Debian 11 installer crashed and reboot
On 8/16/2021 4:25 AM, Andrew M.A. Cater wrote: On Mon, Aug 16, 2021 at 02:30:33PM +0800, John Mok wrote: Hi all, Tried to install Debian 11 guest using netinst, but the installer crashed and reboot automatically. Host: Xen 4.11.4 on Debian 10 Guest: Debian 11 (kernel 5.10) Here is the steps to reproduce the problem:- 1) Either guest BIOS or OVMF boot 2) Select "Expert install" on installation menu Then, the guest crashed and reboot. Another try with the installer on Debian Live 11, it immediately crashed and reboot. Is it a installer bug or something ? Thanks a lot. John Mok I think people would need many more details as to exactly what happens and when it reboots. So: You boot the installer - from just a .iso file / from the .iso flashed to a USB? Can you show what works and at what point it fails? The quick suggestion would be that it's something to do with Xen hypervisor but I'm not in any better position than to guess, since I don't use Xen here. I do know that none of the tests the media team do involve booting on Xen: in most cases we prefer to run on real hardware. Occasionally, some of the tests have to be run on KVM/QEMU. Xen as DomU is untested then. All the very best, as ever, Andy Cater I can say bullseye runs fine as a Xen DomU on both the buster xen-4.11 hypervisor and the bullseye xen-4.14 hypervisor on my workstation, with either BIOS or OVMF boot, but mine is a bullseye image upgraded from buster several months ago. I have not tried the bullseye debian installer on the xen hypervisor. Maybe for installing bullseye on xen you can try installing buster first then upgrade it to bullseye if the debian bullseye installer does not work on the xen hypervisor. Chuck Zmudzinski
