Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #260853 > unrolled thread

Crosshairs in gimp 2.10.22 in Debian 11.7.

Back to article view | Back to linux.debian.user

Contents

  Crosshairs in gimp 2.10.22 in Debian 11.7. peter@easthope.ca - 2023-08-12 04:00 +0200
    Re: Crosshairs in gimp 2.10.22 in Debian 11.7. Dan Ritter <dsr@randomstring.org> - 2023-08-12 13:10 +0200
      Re: Crosshairs in gimp 2.10.22 in Debian 11.7. peter@easthope.ca - 2023-08-12 15:50 +0200
      Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-14 11:30 +0200
        Re: random number generator missing after upgrade David Wright <deblis@lionunicorn.co.uk> - 2023-08-14 15:30 +0200
          Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-14 21:00 +0200
            Re: random number generator missing after upgrade davidson <davidson@freevolt.org> - 2023-08-14 22:30 +0200
              Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-15 07:50 +0200
      Re: upgrade to bookworm broke phpmyadmin Rick Macdonald <rickmacd@shaw.ca> - 2023-08-24 05:30 +0200
        Re: upgrade to bookworm broke phpmyadmin Stefan Monnier <monnier@iro.umontreal.ca> - 2023-08-24 16:00 +0200
          Re: upgrade to bookworm broke phpmyadmin Rick Macdonald <rickmacd@shaw.ca> - 2023-08-24 23:40 +0200
      Re: Please verify Gnome and KDE wiki articles for correctness Jeffrey Walton <noloader@gmail.com> - 2023-08-26 16:30 +0200
        Re: Please verify Gnome and KDE wiki articles for correctness <tomas@tuxteam.de> - 2023-08-26 16:50 +0200
      Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 19:10 +0200
      Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 21:10 +0200
      Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 21:10 +0200
      Re: Debian, Git server, Nginx, Fcgiwrap, and git push can not create  remote object directory David Mehler <dave.mehler@gmail.com> - 2023-09-10 03:30 +0200
      Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-10 18:50 +0200
        Re: usrmerge on root NFS will not be run automatically Javier Barroso <javibarroso@gmail.com> - 2023-09-11 17:30 +0200
      Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 16:30 +0200
        Re: usrmerge on root NFS will not be run automatically Dan Ritter <dsr@randomstring.org> - 2023-09-14 17:20 +0200
          Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 18:10 +0200
          Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 20:30 +0200
            Re: usrmerge on root NFS will not be run automatically Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-14 23:00 +0200
              Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 14:00 +0200
                Re: usrmerge on root NFS will not be run automatically Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-15 15:30 +0200
          Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 22:20 +0200
            Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-10-03 13:50 +0200
          Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 14:00 +0200
            Re: usrmerge on root NFS will not be run automatically Andy Smith <andy@strugglers.net> - 2023-09-15 20:00 +0200
              Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 23:40 +0200
          Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-15 23:40 +0200
            Re: sata driver compataility Q Andy Smith <andy@strugglers.net> - 2023-09-16 00:00 +0200
              Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-16 01:30 +0200
            Re: sata driver compataility Q songbird <songbird@anthive.com> - 2023-09-16 12:10 +0200
              Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-16 13:50 +0200
                Re: sata driver compataility Q songbird <songbird@anthive.com> - 2023-09-16 14:10 +0200
          Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-15 23:50 +0200
          Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-19 03:40 +0200
            Amanda (was: sata driver compataility Q) Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-19 15:00 +0200
              Re: Amanda (was: sata driver compataility Q) gene heskett <gheskett@shentel.net> - 2023-09-19 17:20 +0200
                Re: Amanda (was: sata driver compataility Q) Glenn <ve9gj@napan.com> - 2023-09-19 19:00 +0200
          Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-24 19:30 +0200
            When a random string is not random (was Re: PATH revisited: one PATH  to "rule the [Debian] World") Max Nikulin <manikulin@gmail.com> - 2023-09-25 05:20 +0200
          Re: PATH revisited: one PATH to "rule the [Debian] World" Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-09-24 21:50 +0200
            Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-24 22:00 +0200
              Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 22:50 +0200
                Re: PATH revisited: one PATH to "rule the [Debian] World" Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-09-24 23:00 +0200
                  Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 23:30 +0200
          Message IDs, was Re: PATH revisited: one PATH to "rule the [Debian]  World" David Wright <deblis@lionunicorn.co.uk> - 2023-09-25 05:20 +0200
            Re: Message IDs, was Re: PATH revisited: one PATH to "rule the  [Debian] World" Dan Ritter <dsr@randomstring.org> - 2023-09-25 13:10 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#261665 — Re: usrmerge on root NFS will not be run automatically

Marco wrote: 
> On Fri, 8 Sep 2023 12:26:38 -0400
> Dan Ritter <dsr@randomstring.org> wrote:
> > * have the VM mount the filesystem directly
> 
> How? I can only attach devices (=whole disks) to the VM or mount the
> FS via NFS. I can't attach it as a device because it's not a device,
> rather than a directory with the root file systems of several hosts
> directly on the server. So that doesn't work.


What VM software are you using, and what's the OS on which that
runs?

-dsr-

[toc] | [prev] | [next] | [standalone]

#261671 — Re: usrmerge on root NFS will not be run automatically

On Thu, 14 Sep 2023 11:00:17 -0400
Dan Ritter <dsr@randomstring.org> wrote:

> What VM software are you using

bhyve

…which I know very little about. It's supported on the server, I've
tried it, set up a VM, it works. But the server is mainly serving
NFS shares to various clients.

> and what's the OS on which that runs?

FreeBSD (actually a TrueNAS appliance)

Marco

[toc] | [prev] | [next] | [standalone]

#261673 — Re: usrmerge on root NFS will not be run automatically

On Thu, 14 Sep 2023 13:20:09 -0400
Dan Ritter <dsr@randomstring.org> wrote:

> > FreeBSD (actually a TrueNAS appliance)  
> 
> If it supports the 9P share system, Debian can mount that with
> -t 9p.
> 
> I don't know whether TrueNAS enabled that.

No it does not. I just confirmed, the only choices are raw disk
access (ZVOL), NFS and Samba.

However, usrmerge is a perl script. Can I run it on the server
(after chroot'ing) in a jail (under FreeBSD)? Or does this mess
things up? Just a thought.

Marco

[toc] | [prev] | [next] | [standalone]

#261676 — Re: usrmerge on root NFS will not be run automatically

Still going on with this?

Have you actually looked at those two files:

    /lib/udev/rules.d/60-libsane1.rules and /usr/lib/udev/rules.d/60-libsane1.rules

to see if they're identical or not and to see if you might have an idea
how to merge them?
[ as I suggested a week ago.  ]

`usrmerge` did give you a pretty clear explanation of the problem it's
facing (AFAIC) and I believe it should be very easy to address it (no
need to play with anything funny like setting up a VM or mounting
the disk from some other system).

If you're not sure what to do with those two files, show them to us.


        Stefan


Marco [2023-09-14 20:28:59] wrote:

> On Thu, 14 Sep 2023 13:20:09 -0400
> Dan Ritter <dsr@randomstring.org> wrote:
>
>> > FreeBSD (actually a TrueNAS appliance)  
>> 
>> If it supports the 9P share system, Debian can mount that with
>> -t 9p.
>> 
>> I don't know whether TrueNAS enabled that.
>
> No it does not. I just confirmed, the only choices are raw disk
> access (ZVOL), NFS and Samba.
>
> However, usrmerge is a perl script. Can I run it on the server
> (after chroot'ing) in a jail (under FreeBSD)? Or does this mess
> things up? Just a thought.
>
> Marco

[toc] | [prev] | [next] | [standalone]

#261686 — Re: usrmerge on root NFS will not be run automatically

On Thu, 14 Sep 2023 16:54:27 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Still going on with this?

I am.

> Have you actually looked at those two files:
> 
>     /lib/udev/rules.d/60-libsane1.rules and
> /usr/lib/udev/rules.d/60-libsane1.rules
> 
> to see if they're identical or not and to see if you might have an
> idea how to merge them?

Yes, I did. On some hosts they are identical, on others they're
different. That's why I asked how to handle that.

> `usrmerge` did give you a pretty clear explanation of the problem it's
> facing (AFAIC)

It does indeed.

> and I believe it should be very easy to address it

Everything is easy if you only know how to do it.

As I said, on some hosts they are identical. So what to do? Can I
delete one of them? If yes, which one?

On other hosts they differ, here the first lines:

/lib/

# This file was generated from description files (*.desc)
# by sane-desc 3.6 from sane-backends 1.1.1-debian
#
# udev rules file for supported USB and SCSI devices
#
# For the list of supported USB devices see /lib/udev/hwdb.d/20-sane.hwdb
#
# The SCSI device support is very basic and includes only
# scanners that mark themselves as type "scanner" or
# SCSI-scanners from HP and other vendors that are entitled "processor"
# but are treated accordingly.
#
# If your SCSI scanner isn't listed below, you can add it to a new rules
# file under /etc/udev/rules.d/.
#
# If your scanner is supported by some external backend (brother, epkowa,
# hpaio, etc) please ask the author of the backend to provide proper
# device detection support for your OS
#
# If the scanner is supported by sane-backends, please mail the entry to
# the sane-devel mailing list (sane-devel@alioth-lists.debian.net).
#
ACTION=="remove", GOTO="libsane_rules_end"

…

/usr/lib/

# This file was generated from description files (*.desc)
# by sane-desc 3.6 from sane-backends 1.0.31-debian
#
# udev rules file for supported USB and SCSI devices
#
# For the list of supported USB devices see /lib/udev/hwdb.d/20-sane.hwdb
#
# The SCSI device support is very basic and includes only
# scanners that mark themselves as type "scanner" or
# SCSI-scanners from HP and other vendors that are entitled "processor"
# but are treated accordingly.
#
# If your SCSI scanner isn't listed below, you can add it to a new rules
# file under /etc/udev/rules.d/.
#
# If your scanner is supported by some external backend (brother, epkowa,
# hpaio, etc) please ask the author of the backend to provide proper
# device detection support for your OS
#
# If the scanner is supported by sane-backends, please mail the entry to
# the sane-devel mailing list (sane-devel@alioth-lists.debian.net).
#
ACTION!="add", GOTO="libsane_rules_end"

…

So the file in /lib appears to be newer. So what to do? Can I delete
the one in /usr/lib ?

> (no need to play with anything funny like setting up a VM or
> mounting the disk from some other system).

Which is good because that's not that easy, apparently.

Thank you for your replies and support regarding this matter.

Marco

[toc] | [prev] | [next] | [standalone]

#261689 — Re: usrmerge on root NFS will not be run automatically

> So the file in /lib appears to be newer. So what to do? Can I delete
> the one in /usr/lib ?

Yes.


        Stefan

[toc] | [prev] | [next] | [standalone]

#261674 — Re: usrmerge on root NFS will not be run automatically

On Thu, 14 Sep 2023 15:01:50 -0400
Dan Ritter <dsr@randomstring.org> wrote:

> Is this a mission-critical server?

I'd say so, yes. It's not one single server. It's *all*
workstations.

> i.e. will screwing it up for a day cause other people to be upset

Yes, because no one can use their computer.

> or you to lose money?

Yes.

If I screw with this I'd prefer to do it at night or on a weekend to
keep the systems running during business hours.

> Do you have a good, current backup?

Yes.

> Since it's TrueNAS, I assume you are using ZFS, so: have you sent
> snapshots to some other device recently?

Yes, every three hours. And one before every system upgrade.

[toc] | [prev] | [next] | [standalone]

#262122 — Re: usrmerge on root NFS will not be run automatically

On Thu, 14 Sep 2023 22:17:35 +0200
Marco <lists@homerow.info> wrote:

> If I screw with this I'd prefer to do it at night or on a weekend to
> keep the systems running during business hours.

Followup:

I went through the list and resolved each conflict manually. I
launched usrmerge after every change and deleted/merged the
offending files.

Note that I ran usrmerge on the individual hosts themselves, on NFS
root. Although usrmerge complained that this won't work, it somehow
did. Systems rebooted, all came up fine, no broken packages and the
programs are working.

Thanks for all the support. Case solved.

Marco

[toc] | [prev] | [next] | [standalone]

#261687 — Re: usrmerge on root NFS will not be run automatically

On Thu, 14 Sep 2023 16:43:09 -0400
Dan Ritter <dsr@randomstring.org> wrote:

> The heart of the convert-usrmerge perl script is pretty
> reasonable. However:
> 
> […]
> 
> Similarly, there are calls to stat and du which probably have
> some incompatibilities.
> 
> The effect of running this would be fairly safe, but also not do
> anything: you would get some errors and then it would die.

Ok, then I'll not try that. Would be a waste of time.

> Each of these things could be rewritten to be compatible with
> FreeBSD; I suspect it would take about twenty minutes to an hour,
> most of it testing, for someone who was familiar with FreeBSD's
> userland

I'm not going down that route.

Marco

[toc] | [prev] | [next] | [standalone]

#261693 — Re: usrmerge on root NFS will not be run automatically

Hello,

On Fri, Sep 15, 2023 at 01:52:27PM +0200, Marco wrote:
> On Thu, 14 Sep 2023 16:43:09 -0400
> Dan Ritter <dsr@randomstring.org> wrote:
> > Each of these things could be rewritten to be compatible with
> > FreeBSD; I suspect it would take about twenty minutes to an hour,
> > most of it testing, for someone who was familiar with FreeBSD's
> > userland
> 
> I'm not going down that route.

I haven't followed this thread closely, but is my understanding
correct:

- You have a FreeBSD NFS server with an export that is a root
  filesystem of a Debian 11 install shared by multiple clients

- You're trying to do an upgrade to Debian 12 running on one of the
  clients.

- It tries to do a usrmerge but aborts because NFS is not supported
  by that script?

If so, have you tried reporting a bug on this yet? It seems like an
interesting problem which although being quite a corner case, might
spark the interest of the relevant Debian developers.

If you don't get anywhere with that, I don't think you have much
choice except to take away the root directory tree to a Linux host,
chroot into it and complete the merge there, then pack it up again
and bring it back to your NFS server. Which is very far from ideal.

The suggestions about running a VM on the NFS server probably aren't
going to work as you won't be able to take the directory tree out of
use and export it as a block device to the VM. Or rather, you could
do that, but it's probably not quicker/easier than the method of
taking a copy of it elsewhere then bringing it back.

The option of making the usrmerge script work from FreeBSD might not
be too technically challenging but I wouldn't want to do it without
assistance from the Debian developers responsible for the script.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#261700 — Re: usrmerge on root NFS will not be run automatically

On Fri, 15 Sep 2023 17:55:06 +0000
Andy Smith <andy@strugglers.net> wrote:

> I haven't followed this thread closely, but is my understanding
> correct:
> 
> - You have a FreeBSD NFS server with an export that is a root
>   filesystem of a Debian 11 install shared by multiple clients

Almost. It's not *one* Debian installation, it's many (diskless
workstations PXE boot). Each host has it's own root on the NFS.
Some stuff is shared, but that's not relevant here.

> - You're trying to do an upgrade to Debian 12 running on one of the
>   clients.

Not on one on *all* clients.

> - It tries to do a usrmerge but aborts because NFS is not supported
>   by that script?

Correct. Strangely the usrmerge script succeeded on one host. But on
all others it throws errors. Either relating to NFS being not
supported or because of duplicate files.

> If so, have you tried reporting a bug on this yet?

No I haven't. As far as I understand it's a known issue and the
developer has decided to just have the script fail on NFS.

> If you don't get anywhere with that, I don't think you have much
> choice except to take away the root directory tree to a Linux host,
> chroot into it and complete the merge there, then pack it up again
> and bring it back to your NFS server. Which is very far from ideal.

I'll try to solve the conflicts manually. If that fails, that's what
I have to do, I guess. I didn't expect that level of fiddling with
system files for a simple upgrade. But hey, here we are now.

> The suggestions about running a VM on the NFS server probably aren't
> going to work as you won't be able to take the directory tree out of
> use and export it as a block device to the VM.

Indeed.

> The option of making the usrmerge script work from FreeBSD might not
> be too technically challenging but I wouldn't want to do it without
> assistance from the Debian developers responsible for the script.

I won't do that. I don't speak Perl and will not rewrite the
usrmerge script.

Marco

[toc] | [prev] | [next] | [standalone]

#261698 — Re: sata driver compataility Q

On 9/15/23 15:56, Dan Ritter wrote:
> gene heskett wrote:
>> Greetings all;
>>
>> I've just ordered some stuff to rebuild or expand my Raid setup.
>> This 16 port sata-III pci-e card:
>> <https://www.amazon.com/dp/B09L184W57?smid=A2H818KAC5I4D1&ref_=chk_typ_imgToDp&th=1>
>> along with a bigger drive cage, cables and such and some gigastone 2T drives
>> to make a raid big enough to run amanda. And maybe put a new card in front
>> of my 2T /home raid10.
>>
>> The card claims linux compatibility.
>>
>> Can anyone advise me on the gotcha's of such a 16 port beast?
> 
> What you actually have there is 1 SATA-3 controller which should
> be able to support 4 disks, and 4 port multipliers to support
> 16.
> 
> Effectively, every group of four disks is competing against
> themselves. So performance is going to be mediocre.
> 
Since the pci-e plug is the narrow one I suspected as much, the data 
path is too narrow, This asus mobo has 6 ports but I'd assume the mobo 
ports would be wider, perhaps even x4 but it is also not stated,
The existing 4 1T per drive raid10 is on its own x1 based 6 port 
controller. The other 2 ports are not used at present,

This setup worked instantly under buster and bullseye, but takes from 30 
secs to 5 minutes to open a write requestor window asking where to put 
the download I clicked on under bookworrm.  And just as often as I've 
mentioned it the subject of the reply if any, is changed w/o changing 
the subject line, to ignore it.


> It should work, though, as a giant dumping ground.
> 
Such as an amanda backup raid, and running it the wee hours, I could 
care less how long it takes as long as it is done by 05:30 or 06:00. If 
I can rearrange the usb breakouts, I can uncover another pci-e x1 socket 
for this card.

> But why are you buying 16 x 2TB disks, if not for performance?

I'm not, I'll only have 6 of them when the rest get here.  One of them 
may go into one of my milling machines to replace the last spinning rust 
on the property.

> I've never heard of Gigastone and can offer no assessment of
> them.
Relatively new on amazon. A month ago nearly the only 2T available, in a 
month the 2T list has been had the decimal point shifted right at least 
1 place. And the prices have risen 10 bucks. $89/copy today.
> 
> -dsr-
> .
Take care and stay well, Dan.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[toc] | [prev] | [next] | [standalone]

#261702 — Re: sata driver compataility Q

Hello,

On Fri, Sep 15, 2023 at 05:35:40PM -0400, gene heskett wrote:
> This setup worked instantly under buster and bullseye, but takes from 30
> secs to 5 minutes to open a write requestor window asking where to put the
> download I clicked on under bookworrm.

I think you should work out why that happens before spending a lot
of money on new hardware. It doesn't seem at all likely to me that
your existing hardware is at fault. Buying new hardware risks
experiencing the same thing with still no idea why.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#261704 — Re: sata driver compataility Q

On 9/15/23 17:56, Andy Smith wrote:
> Hello,
> 
> On Fri, Sep 15, 2023 at 05:35:40PM -0400, gene heskett wrote:
>> This setup worked instantly under buster and bullseye, but takes from 30
>> secs to 5 minutes to open a write requestor window asking where to put the
>> download I clicked on under bookworrm.
> 
> I think you should work out why that happens before spending a lot
> of money on new hardware. It doesn't seem at all likely to me that
> your existing hardware is at fault. Buying new hardware risks
> experiencing the same thing with still no idea why.
> 
> Thanks,
> Andy
> 
I won't argue on that point Andy, but it now been several months asking 
the same question from different angles and not getting a single helpful 
reply. I know my reputation is bad because I often use the box I'm 
supposed to stay inside of, as kindling to start the next campfire. I 
don't "stay inside that famous box" unless there is someone outside 
shooting at me, it which case I might shoot back. Computers can do 
anything you can write an interface to tickle the hardware for.

Now if someone can have me check something that might be aglay, my 
fingers to do that check are at your disposal. It eventually works, 100% 
of the time. But why the 30 sec to 5 minute delay before it allows me to 
do what I asked?

Frustrated is the PC word, but that is certainly not how I describe it 
in my lonelyness. There is not anyone here to hear me rant except me, 
which is probably a "good thing".

Thanks, take care and stay well Andy.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[toc] | [prev] | [next] | [standalone]

#261714 — Re: sata driver compataility Q

gene heskett wrote:
...
> This setup worked instantly under buster and bullseye, but takes from 30 
> secs to 5 minutes to open a write requestor window asking where to put 
> the download I clicked on under bookworrm.

  trace the first part of the process and see what is 
taking so long.


  songbird

[toc] | [prev] | [next] | [standalone]

#261715 — Re: sata driver compataility Q

On 9/16/23 06:07, songbird wrote:
> gene heskett wrote:
> ...
>> This setup worked instantly under buster and bullseye, but takes from 30
>> secs to 5 minutes to open a write requestor window asking where to put
>> the download I clicked on under bookworrm.
> 
>    trace the first part of the process and see what is
> taking so long.

I'd love to, but how do you trace a mouse click?  All the 
"alphabet-trace" utils I know are cli only. Probably my fault, but...
> 
> 
>    songbird
> 
> .

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[toc] | [prev] | [next] | [standalone]

#261716 — Re: sata driver compataility Q

gene heskett wrote:
> On 9/16/23 06:07, songbird wrote:
>> gene heskett wrote:
>> ...
>>> This setup worked instantly under buster and bullseye, but takes from 30
>>> secs to 5 minutes to open a write requestor window asking where to put
>>> the download I clicked on under bookworrm.
>> 
>>    trace the first part of the process and see what is
>> taking so long.
>
> I'd love to, but how do you trace a mouse click?  All the 
> "alphabet-trace" utils I know are cli only. Probably my fault, but...

  replace the /usr/bin/<name> by a script which traces 
the <name> in question...  or if it is X related there
are probably ways of tracing X.

  it might be a desktop, greeter or a window manager 
binary of some type but you should eventually be able 
to figure out what is going on.


  songbird

[toc] | [prev] | [next] | [standalone]

#261701 — Re: sata driver compataility Q

On 9/15/23 15:56, Dan Ritter wrote:
> gene heskett wrote:
>> Greetings all;
>>
>> I've just ordered some stuff to rebuild or expand my Raid setup.
>> This 16 port sata-III pci-e card:
>> <https://www.amazon.com/dp/B09L184W57?smid=A2H818KAC5I4D1&ref_=chk_typ_imgToDp&th=1>
>> along with a bigger drive cage, cables and such and some gigastone 2T drives
>> to make a raid big enough to run amanda. And maybe put a new card in front
>> of my 2T /home raid10.
>>
>> The card claims linux compatibility.
>>
>> Can anyone advise me on the gotcha's of such a 16 port beast?
> 
> What you actually have there is 1 SATA-3 controller which should
> be able to support 4 disks, and 4 port multipliers to support
> 16.
> 
And I forgot to ask, which would be faster, 4 drives on port1 1-4, or 4 
drives on ports 1-5-9-13?

> Effectively, every group of four disks is competing against
> themselves. So performance is going to be mediocre.
> 
> It should work, though, as a giant dumping ground.
> 
> But why are you buying 16 x 2TB disks, if not for performance?
> 
> I've never heard of Gigastone and can offer no assessment of
> them.
> 
> -dsr-
> .

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[toc] | [prev] | [next] | [standalone]

#261756 — Re: sata driver compataility Q

On 9/18/23 07:57, Dan Ritter wrote:
> gene heskett wrote:
[...]
>>> It looks like the motherboard shares some PCIe and/or SATA lanes between
>>> SATA ports and M.2 ports, so you must be careful with your choices.?? I
>>> suggest installing an M.2 PCIe x4 SSD into slot M.2_1 and configuring it
>>> for "PCIE mode", so that it works and all 6 SATA ports work.?? You will
>>> want to use EUFI mode and GPT when installing Debian.
>>>
>>>
>> Based on this, and a full sized manual printout,  I've ordered a 2T WD
>> Black, supposedly a 2280 device. $100.
>>
>> Question, when I put this in, what happens to the 32GB of dimms? How does
>> this fit into the architecture?  I assume this isn't volatile but is quick
>> storage.
> 
> The DIMM slots are different from the M.2 slots. The M.2 slots
> are small PCIe interfaces; the installation procedure is to
> insert the 2280 (22mm x 80mm) card at a slight upward angle,
> then press it down and screw it in. It may ship with a glued-on
> heat spreader or tiny radiator; if so, use it, don't peel it
> off.
> 
> Note that it should appear as /dev/nvme0n1 or similar, rather
> than /dev/sda. Partitions will be /dev/nvme0n1p1, p2...
> 
> The NVM bits stands for non-volatile memory; it's an SSD with a
> different interface.
> 
>> I propose to put this in as suggested, which should leave all 6 sata-III's
>> available, Install bookworm to it, w/o the current ectra controller get it
>> going, then put 3 of the 2T gigastones on sata1-2-3, use the bios to make a
>> raid5 of them and mount it as /home, prove it works with some throw away
>> stuff, then plug the existing raid10 controller & mount it as moi, then
>> format the raid5 again with gparted,
> 
> You should use mdadm rather than a BIOS RAID system -- better
> recovery to other systems, more understandable error messages,
> better support for fixing things that might go wrong.

Thanks, I will.
> 
> If the new drives are sda through sdf something like this is what
> you want:
> 
> mdadm --create /dev/md/gsmoi5 -l raid5 -n 3 /dev/sda /dev/sdb /dev/sdc
> mkfs.ext4 /dev/md/gsmoi5
> mount /dev/md/gsmoi5 /home
> 
> 
> and for your second set:
> 
> mdadm --create /dev/md/gsamanda5 -l raid5 -n 3 /dev/sdd /dev/sde /dev/sdf
> mkfs.ext4 /dev/md/gsamanda5
> mount /dev/md/gsamanda5 /amanda
> 
> 
>> Suggestions re other, more recent solutions will be accepted and studied.
>> Definitely must support backing up other machines of varying architectures
>> on my local network. In addition to a 4 pack of linux running wintel stuff,
>> there's the potential for 5 or so arms too. Gcodes for 3d printers are all
>> unrolled loops and bulky as can be.
> 
> The most flexible backup systems are the hardest to configure,
> but nothing is much worse than amanda.
> 
> You might like borg. Borg is in Debian as 'borgbackup'.
> 
> In the other direction, using rsnapshot over ssh is relatively
> simple and comes with the distinct advantage over both amanda
> and borg that the backups are stored as normal files in a normal
> filesystem, so recovery from an accidental deletion of a file or
> directory is very straightforward.
> 
Compared to the setup required for amanda, that sounds very inviting. 
Amanda has a very steep learning curve just because it is so versatile 
I'm still waiting on stuff, so no more actual progress.

Thanks Dan, tae care & stay well.
> -dsr-
> .

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[toc] | [prev] | [next] | [standalone]

#261758 — Amanda (was: sata driver compataility Q)

> Compared to the setup required for amanda, that sounds very inviting. Amanda
> has a very steep learning curve just because it is so versatile I'm still
> waiting on stuff, so no more actual progress.

I used Amanda many years ago and was quite pleased with it, but I must
say I'm having a hard time imagining it in my current world where tapes
don't make much sense for backups.

What are the use cases where Amanda still beats the pants down of
competitors like Borg or Bup?


        Stefan

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web