Re: [gentoo-user] Something not right with LVM, I think.
Michael wrote: > On Sunday, 29 October 2023 10:40:19 GMT Neil Bothwick wrote: >> On Sun, 29 Oct 2023 03:16:05 -0500, Dale wrote: >>> I have several external hard drives. I have one that is, weird. Others >>> work fine. When I first power up the drive, cryptsetup can't open it >>> because it doesn't exist yet. >> Is it the drive/enclosure taking too long to power up? There are kernel >> options to delay the boot to allow for USB devices to become available, >> such as usb-storage.delay_use. Try setting a long delay and, if that >> fixes it, reducing the delay until you find a suitable setting. > There's also a rootwait kernel cmdline option. I had to use this to be able > to boot a rootfs on a (sluggish) spinning drive on a USB docking station, but > I suspect this does not apply to your setup if the rootfs is not stored on > this drive. > > Either way, there may be a case for setting rc_after=lvm in the device_mapper > configuration, to make sure all ducks are in a row as the devices and fs > containers are initialised in the correct order. You can manage rc service > priorities by playing with rc_after and rc_need options. > > You mention two things, 770T works fine with this combo of external drives > and > the problem started after you enabled crypto hardware acceleration in the FX > kernel. Assuming these observations are reliably repeatable, then this could > be explained as follows: > > The 770T performs decryption slowly using its CPU core(s), as well as loading > drivers and initialising any rc services including LVM. This means any > initialisation by the kernel of (sluggish) hardware will give it enough time > to get up and running. With the FX system, everything happens much faster > and > at some point it trips over itself, because the sluggish hardware hasn't got > its boots on in a timely fashion. I may try to boot my old kernel and see if it works as it should there. I'm pretty sure I connected the new enclosure a couple times tho to the old kernel and it worked. I'm just not 100% sure. I'm just wondering if something I enabled might affect how it works somehow. I mostly followed the Gentoo dm-crypt wiki except that I enabled a few extra encryption logarithms. Thing is, given the 770T has a newer kernel than my main rig, hard to compare. I got my backups moved around so I won't need to hook it back up for a week or so. If I get the chance to reboot tho, I can always test it then. Wol, I used USB a few times on some old enclosures I had. I bricked a few hard drives with those things. I was always getting data errors and eventually, the drives would die. Oddly, one of the enclosures worked fine. I stopped using them when I bought the ones I use now. Dale :-) :-)
Re: [gentoo-user] Something not right with LVM, I think.
On 29/10/2023 14:28, Dale wrote: I don't see anything different between the two types of enclosures except I have to restart LVM with one of them. Weird for sure. Well, on the linux raid wiki I explicitly tell people not to use USB drives for raid. "We don't know why, but it seems guaranteed to cause problems". Cheers, Wol
Re: [gentoo-user] rsync options after backup restore. Transfer speed again.
On 22/10/2023 09:50, Dale wrote: I've read about using rsync as a daemon. It is supposed to be faster. For some reason, I just never got around to trying it. It would likely be a good idea to work on that. It would likely be really handy when moving large amounts of data. I may try to read a howto on the Gentoo wiki or something. See what all it involves. Run the daemon on the NAS. For each file where the metadata differs, the NAS will send a bunch of block checksums to your rsync command (or the other way round). If all the checksums agree, then the files are identical, without having to send the file over the network. If only a few checksums differ, only a few blocks have to be sent. In other words, using a daemon will massively reduce the amount of data going across the network, at the expense of the NAS having to scan and checksum every "file of interest". A pretty cheap trade-off, imho. Cheers, Wol
Re: [gentoo-user] libavcodec causes general protection fault when compiled with gcc 13
netfab wrote: > > Have a look at ¹ to see if it matches your case. > Please try the workaround suggested in comment 4 (set CPU_FLAGS_X86 > and re-emerge ffmpeg). Does it help ? > 1. https://bugs.gentoo.org/915384 Yes, it helped. I have provided some more information in that bug report. (Of course, I had searched the bug database, but obviously with wrong search terms.) Thanks a lot - I would never have thought of that myself (didn't even know "CPU_FLAGS_X86" at all until now). -Matt
Re: [gentoo-user] Something not right with LVM, I think.
Neil Bothwick wrote: > On Sun, 29 Oct 2023 03:16:05 -0500, Dale wrote: > >> I have several external hard drives. I have one that is, weird. Others >> work fine. When I first power up the drive, cryptsetup can't open it >> because it doesn't exist yet. > Is it the drive/enclosure taking too long to power up? There are kernel > options to delay the boot to allow for USB devices to become available, > such as usb-storage.delay_use. Try setting a long delay and, if that > fixes it, reducing the delay until you find a suitable setting. > > I connect by eSATA. I hate using USB for a hard drive. This is when I have my system already booted so I'm hot plugging. Also, I use cryptsetup manually. I should have mentioned that in the original post. I did plug up one of my other external drives and watch /var/log/messages. Both have the same things listed when I power up the external drives. I couldn't tell anything different. Also, they all power up in the same time frame. Usually, 10 seconds or so from power on to nothing more in messages. The enclosure that doesn't work right is a StarTech SAT3510BU2E. The ones that work fine, they are Rosewill RX304APU335B. Both of those models have fans. They have both eSATA and USB but I've never used the USB ports. All the external drives appear the same in every way except that one enclosure requires me to restart LVM to get that last bit cryptsetup needs. I can't make any sense of it. I have two of the StarTech ones. I may try the other one. See if it does the same thing. What's odd, it seems to work fine on the 770T system with a fresh install and new kernel. I don't see anything different between the two types of enclosures except I have to restart LVM with one of them. Weird for sure. Any ideas? Dale :-) :-)
Re: [gentoo-user] Something not right with LVM, I think.
On Sunday, 29 October 2023 10:40:19 GMT Neil Bothwick wrote: > On Sun, 29 Oct 2023 03:16:05 -0500, Dale wrote: > > I have several external hard drives. I have one that is, weird. Others > > work fine. When I first power up the drive, cryptsetup can't open it > > because it doesn't exist yet. > > Is it the drive/enclosure taking too long to power up? There are kernel > options to delay the boot to allow for USB devices to become available, > such as usb-storage.delay_use. Try setting a long delay and, if that > fixes it, reducing the delay until you find a suitable setting. There's also a rootwait kernel cmdline option. I had to use this to be able to boot a rootfs on a (sluggish) spinning drive on a USB docking station, but I suspect this does not apply to your setup if the rootfs is not stored on this drive. Either way, there may be a case for setting rc_after=lvm in the device_mapper configuration, to make sure all ducks are in a row as the devices and fs containers are initialised in the correct order. You can manage rc service priorities by playing with rc_after and rc_need options. You mention two things, 770T works fine with this combo of external drives and the problem started after you enabled crypto hardware acceleration in the FX kernel. Assuming these observations are reliably repeatable, then this could be explained as follows: The 770T performs decryption slowly using its CPU core(s), as well as loading drivers and initialising any rc services including LVM. This means any initialisation by the kernel of (sluggish) hardware will give it enough time to get up and running. With the FX system, everything happens much faster and at some point it trips over itself, because the sluggish hardware hasn't got its boots on in a timely fashion. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: OFF TOPIC Need Ubuntu network help: boot loader info
On 19/10/2023 12:55, Neil Bothwick wrote: On Wed, 18 Oct 2023 23:49:25 -0500, Dale wrote: That config kinda reminds me of the old grub. A title line, location of kernel and then options. Sounds easy enough. The new grub config is almost impossible to config by hand. They had to make a tool to do it. That says a lot there. ;-) GRUB2 was designed to be able to create a config for anything automatically, such as from an installer. It does that very well, but is total overkill for Gentoo-like people that like to stay in control. Such a shame it doesn't work. :-) I tried to install SUSE dual boot, and it broke the installer - NOTHING would boot. I needed a rescue disk to fix the mess ... Cheers, Wol
Re: [gentoo-user] libavcodec causes general protection fault when compiled with gcc 13
Hi,
Le 29/10/23 à 11:29, Matthias Hanft a tapoté :
> I don't have anything special in /etc/portage/make.conf - just
> as usual:
>
> CFLAGS="-march=native -O2 -pipe"
> CXXFLAGS="${CFLAGS}"
> MAKEOPTS="-j2"
> CHOST="x86_64-pc-linux-gnu"
>
> Any hints?
Have a look at ¹ to see if it matches your case.
Please try the workaround suggested in comment 4 (set CPU_FLAGS_X86
and re-emerge ffmpeg). Does it help ?
1. https://bugs.gentoo.org/915384
Re: [gentoo-user] Something not right with LVM, I think.
On Sun, 29 Oct 2023 03:16:05 -0500, Dale wrote: > I have several external hard drives. I have one that is, weird. Others > work fine. When I first power up the drive, cryptsetup can't open it > because it doesn't exist yet. Is it the drive/enclosure taking too long to power up? There are kernel options to delay the boot to allow for USB devices to become available, such as usb-storage.delay_use. Try setting a long delay and, if that fixes it, reducing the delay until you find a suitable setting. -- Neil Bothwick Keep your words soft and sweet in case you have to eat them. pgphD4BwPAYne.pgp Description: OpenPGP digital signature
[gentoo-user] libavcodec causes general protection fault when compiled with gcc 13
Hi,
after compiling ffmpeg (which includes libavcodec) with gcc 13,
everything which uses libavcodec crashes with general protection
fault. This includes stand-alone use of ffmpeg, but also
minidlna (and supposedly some more packages).
Oct 29 11:16:08 home01 kernel: traps: minidlnad[11961] general protection fault
ip:7f44fcc1e2ea sp:7f44fbf48e20 error:0 in
libavcodec.so.60.3.100[7f44fcbb2000+73b000]
After recompiling package ffmpeg with gcc 12, everything works fine.
What could be the reason for this? Of course, I'd like to delete
gcc 12 after some period of time.
I don't have anything special in /etc/portage/make.conf - just
as usual:
CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"
CHOST="x86_64-pc-linux-gnu"
Any hints?
Thanks,
-Matt
[gentoo-user] Something not right with LVM, I think.
Howdy, I have several external hard drives. I have one that is, weird. Others work fine. When I first power up the drive, cryptsetup can't open it because it doesn't exist yet. This is the relevant part of lsblk -f when it doesn't work: NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdr └─sdr1 LVM2_member LVM2 001 SLbMcr-d3M9-XONQ-jPtM-Meyd-H6tY-hjSc5S Then I restart lvm, which I don't like doing when things are running. :/ NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdr └─sdr1 LVM2_member LVM2 001 SLbMcr-d3M9-XONQ-jPtM-Meyd-H6tY-hjSc5S └─10tb-10tb--lv crypto_LUKS 2 eab6268e-721b-4c72-aef3-0ecc319f18d4 As you can see, when I restart the LVM service, it adds that last little bit which is what cryptsetup needs to open. My question is this, why do I need to restart lvm for that? Also, everything for that drive shows up just fine in pvs, vgs and lvs. They all recognize the drive as being connected and ready. I might add, it also shows up under /dev/mapper as well, before I restart LVM that is. This seems to have started when I added some encryption options to the new kernel. Thing is, I also started using this external case about the same time. Also, it seems to work fine on the 770T. I tested it on that too. Here is some additional info: root@fireball / # emerge -pv sys-fs/lvm2 sys-fs/cryptsetup These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 63.13 s (backtrack: 0/50). [ebuild R ] sys-fs/lvm2-2.03.21-r1::gentoo USE="lvm readline udev -sanlock (-selinux) -static -static-libs -systemd -thin -valgrind" 0 KiB [ebuild R ] sys-fs/cryptsetup-2.6.1:0/12::gentoo USE="argon2 nls openssl udev -fips -gcrypt -kernel -nettle -pwquality -ssh -static -static-libs -test -urandom" 0 KiB Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB root@fireball / # Anyone have a idea on why I have to restart LVM to get this one drive to work? Once I restart LVM, everything works fine. Is it LVM or something else? It seems LVM is working, it is seeing the drives. However, restarting LVM fixes it. Is it something to do with cryptsetup and restarting LVM fixes it? Open to ideas. Need more info, let me know, maybe how to get it as well. Thanks. Dale :-) :-)
