Re: [gentoo-user] ssh problem
211226 Michael wrote: > On Sun, 26 Dec 2021 11:42:41 -0500, Philip Webb wrote: >> I want to login to a remote site using 'ssh'. >> The response I get is "Unable to negotiate with port >> : no matching host key type found. Their offer: ssh-rsa,ssh-dss". >> Yesterday, I updated 'openssh' : > It sounds like the host may be running an old version of sshd > that only offers ciphers that are now disabled by default in newer releases. > You can get round this by enabling those ciphers for this host, > with something like this in ssh_config : 'HostKeyAlgorithms +ssh-rsa'. Thanks to all the respondents : adding that line makes it work again. I've made a note of the Ssh help site & updated by own nn too. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Long boot time after kernel update
Le lun. 27 déc. 2021 à 01:44, Wols Lists a écrit : > On 26/12/2021 18:50, Jacques Montier wrote: > > Hello all, > > > > I update to the last stable kernel 5.15.11-gentoo with the same > > configuration as the old kernel and now, the boot time is quite long. > > > > Test : > > 5.10.76-gentoo-r1 kernel : boot time 30s > > 5.15.11-gentoo kernel : boot time 70s > > > > My setup (non EFI) : > > - SSD 250 Go : /dev/sdd1 ext2 for boot and /dev/sdd2 ext4 for / > > - SSD 250 Go /dev/sdc1 ext4 for home > > - Two 2T sata disks Seagate BarraCuda 3.5 /dev/sda1 ext4 for data and > > /dev/sdb1 ext4 for data backup (Not Raid) > > > > With the new kernel, the two Seagate disks seem to make the boot time > > quite longer. > > > > Test : > > booting without mounting the disks : 20s > > booting with mounting only one disk : 25s > > booting with both disks : more than 60s > > > > Testing the disks : > > - smartctl -s on -a /dev/sda and smartctl -s on -a /dev/sdb : No error > > reported. > > - fsck -a /dev/sda1 and fsck -a /dev/sdb1 : clean > > - e2fsck -cfpv /dev/sda1 : clean > > > > Nevertheless, dmesg shows a lot of errors (attached image) with the new > > kernel. > > Those errors do not appear with 5.10.76-gentoo-r1 kernel. > > > > I'm rather confused... > > Have you any idea ? > > > What does fdisk print say? Are your partitions mis-aligned? > > Unlikely, but it depends how long ago they were partitioned. There's all > this stuff about switching from 512B to 4K sectors and that *could* be > the problem. > > Cheers, > Wol > > Thanks Wol, The output of fdisk for my two 2T disks : ... Disque /dev/sda : 1,82 TiB, 2000398934016 octets, 3907029168 secteurs Modèle de disque : ST2000DM008-2FR1 Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : dos Identifiant de disque : 0xe0e26837 Périphérique Amorçage DébutFin Secteurs Taille Id Type /dev/sda1 2048 3907028991 3907026944 1,8T 83 Linux Disque /dev/sdb : 1,82 TiB, 2000398934016 octets, 3907029168 secteurs Modèle de disque : ST2000DM008-2FR1 Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : dos Identifiant de disque : 0x7c91a79a Périphérique Amorçage DébutFin Secteurs Taille Id Type /dev/sdb1 2048 3907028991 3907026944 1,8T 83 Linux ... Well, i don't know if my partitions are aligned or mis-aligned... How could i get it ? Cheers, -- Jacques
Re: [gentoo-user] Long boot time after kernel update
On 27/12/2021 11:07, Jacques Montier wrote: Well, i don't know if my partitions are aligned or mis-aligned... How could i get it ? fdisk would have spewed a bunch of warnings. So you're okay. I'm not sure of the details, but it's the classic "off by one" problem - if there's a mismatch between the kernel block size and the disk block size any writes required doing a read-update-write cycle which of course knackered performance. I had that hit a while back. But seeing as fdisk isn't moaning, that isn't the problem ... Cheers, Wol
Re: [gentoo-user] Long boot time after kernel update
On Monday, 27 December 2021 11:32:39 GMT Wols Lists wrote: > On 27/12/2021 11:07, Jacques Montier wrote: > > Well, i don't know if my partitions are aligned or mis-aligned... How > > could i get it ? > > fdisk would have spewed a bunch of warnings. So you're okay. > > I'm not sure of the details, but it's the classic "off by one" problem - > if there's a mismatch between the kernel block size and the disk block > size any writes required doing a read-update-write cycle which of course > knackered performance. I had that hit a while back. > > But seeing as fdisk isn't moaning, that isn't the problem ... > > Cheers, > Wol I also thought of misaligned boundaries when I first saw the error, but the mention of Seagate by the OP pointed me to another edge case which crept up with zstd compression on ZFS. I'm mentioning it here in case it is relevant: https://livelace.ru/posts/2021/Jul/19/unaligned-write-command/ HTH, signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Long boot time after kernel update
On 27/12/2021 13:40, Michael wrote: On Monday, 27 December 2021 11:32:39 GMT Wols Lists wrote: On 27/12/2021 11:07, Jacques Montier wrote: Well, i don't know if my partitions are aligned or mis-aligned... How could i get it ? fdisk would have spewed a bunch of warnings. So you're okay. I'm not sure of the details, but it's the classic "off by one" problem - if there's a mismatch between the kernel block size and the disk block size any writes required doing a read-update-write cycle which of course knackered performance. I had that hit a while back. But seeing as fdisk isn't moaning, that isn't the problem ... Cheers, Wol I also thought of misaligned boundaries when I first saw the error, but the mention of Seagate by the OP pointed me to another edge case which crept up with zstd compression on ZFS. I'm mentioning it here in case it is relevant: https://livelace.ru/posts/2021/Jul/19/unaligned-write-command/ that might be of interest to me ... I'm getting system lockups but it's not an SSD. I've got two IronWolves and a Barracuda. But I notice the OP has a Barra*C*uda. Note the different spelling. That's a shingled drive I believe, which shouldn't make a lot of difference in light usage, but you don't want to hammer it! Cheers, Wol
Re: [gentoo-user] Long boot time after kernel update
On Mon, Dec 27, 2021 at 8:46 AM Wols Lists wrote:
>
> On 27/12/2021 13:40, Michael wrote:
> > On Monday, 27 December 2021 11:32:39 GMT Wols Lists wrote:
> >> On 27/12/2021 11:07, Jacques Montier wrote:
> >>> Well, i don't know if my partitions are aligned or mis-aligned... How
> >>> could i get it ?
> >>
> >> fdisk would have spewed a bunch of warnings. So you're okay.
> >>
> >> I'm not sure of the details, but it's the classic "off by one" problem -
> >> if there's a mismatch between the kernel block size and the disk block
> >> size any writes required doing a read-update-write cycle which of course
> >> knackered performance. I had that hit a while back.
> >>
> >> But seeing as fdisk isn't moaning, that isn't the problem ...
> >>
> >> Cheers,
> >> Wol
> >
> > I also thought of misaligned boundaries when I first saw the error, but the
> > mention of Seagate by the OP pointed me to another edge case which crept up
> > with zstd compression on ZFS. I'm mentioning it here in case it is
> > relevant:
> >
> > https://livelace.ru/posts/2021/Jul/19/unaligned-write-command/
> >
> that might be of interest to me ... I'm getting system lockups but it's
> not an SSD. I've got two IronWolves and a Barracuda.
>
> But I notice the OP has a Barra*C*uda. Note the different spelling.
> That's a shingled drive I believe, which shouldn't make a lot of
> difference in light usage, but you don't want to hammer it!
I've run into this issue and I've seen rare reports of it online, but
no sign of resolution. I'm pretty sure it is some sort of bug in the
kernel. I've tended to see it under load, and mostly when using zfs.
I do not use zstd compression and do not have any zvols on the pools
that had this issue. So, either there are multiple problems, or that
linked post did not correctly identify the root cause (which seems
likely). I'm guessing it is triggered under load and perhaps using
zstd compression helps create that load.
I haven't seen it much lately - probably because I've shifted a lot of
my load to lizardfs and also I'm using USB3 hard drives for the bulk
of my storage and since these seem to be ATA errors the removal of the
SATA host and associated drivers may bypass the problem.
I doubt this has anything to do with physical/logical sector size and
partition alignment. The disks should still work correctly if the
physical sectors aren't aligned - they should just have performance
degradation. In any case, all my drives are aligned on physical
sector boundaries. I'm not familiar enough with ATA to understand
what the actual errors are referring to.
Here is an example of one of the errors I've had in the past from one
of these situations. A zpool scrub usually clears up any damage and
then the drive works normally until the issue happens again (which
hasn't happened in quite a while for me now). I have a dump of the
SMART logs and the kernel ring buffer:
ATA Error Count: 1
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 1 occurred at disk power-on lifetime: 12838 hours (534 days + 22 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
84 51 e0 88 cc c3 06 Error: ICRC, ABRT at LBA = 0x06c3cc88 = 113495176
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- --
61 00 c0 68 cb c3 40 08 2d+00:45:18.962 WRITE FPDMA QUEUED
60 00 b8 98 67 00 40 08 2d+00:45:18.917 READ FPDMA QUEUED
60 00 b0 98 65 00 40 08 2d+00:45:18.916 READ FPDMA QUEUED
60 00 a8 98 66 00 40 08 2d+00:45:18.916 READ FPDMA QUEUED
61 00 a0 68 ca c3 40 08 2d+00:45:18.879 WRITE FPDMA QUEUED
[354064.268896] ata6.00: exception Emask 0x11 SAct 0x100 SErr
0x48 action 0x6 frozen
[354064.268907] ata6.00: irq_stat 0x4808, interface fatal error
[354064.268910] ata6: SError: { 10B8B Handshk }
[354064.268915] ata6.00: failed command: WRITE FPDMA QUEUED
[354064.268919] ata6.00: cmd 61/00:c0:68:cb:c3/07:00:06:01:00/40 tag
24 ncq dma 917504 out
res 50/00:00:68:cb:c3/00:07:06:01:00/40 Emask
0x10 (ATA bus error)
[354064.268922] ata6.00: status: { DRDY }
[354064.268926] ata6: hard resetting link
[354064.731093] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[354064.734739] ata6.00: configured for UDMA/133
[35406
Re: [gentoo-user] Long boot time after kernel update
Wols Lists wrote: > On 27/12/2021 13:40, Michael wrote: >> On Monday, 27 December 2021 11:32:39 GMT Wols Lists wrote: >>> On 27/12/2021 11:07, Jacques Montier wrote: Well, i don't know if my partitions are aligned or mis-aligned... How could i get it ? >>> >>> fdisk would have spewed a bunch of warnings. So you're okay. >>> >>> I'm not sure of the details, but it's the classic "off by one" >>> problem - >>> if there's a mismatch between the kernel block size and the disk block >>> size any writes required doing a read-update-write cycle which of >>> course >>> knackered performance. I had that hit a while back. >>> >>> But seeing as fdisk isn't moaning, that isn't the problem ... >>> >>> Cheers, >>> Wol >> >> I also thought of misaligned boundaries when I first saw the error, >> but the >> mention of Seagate by the OP pointed me to another edge case which >> crept up >> with zstd compression on ZFS. I'm mentioning it here in case it is >> relevant: >> >> https://livelace.ru/posts/2021/Jul/19/unaligned-write-command/ >> > that might be of interest to me ... I'm getting system lockups but > it's not an SSD. I've got two IronWolves and a Barracuda. > > But I notice the OP has a Barra*C*uda. Note the different spelling. > That's a shingled drive I believe, which shouldn't make a lot of > difference in light usage, but you don't want to hammer it! > > Cheers, > Wol > > I don't recall seeing this mentioned but this may be part of the issue unless I'm missing something that rules this out. Could it be a drive is a SMR drive? I recently made a new backup after wiping out the drive. I know the backup drive is a SMR drive. At first, it copied at a fairly normal speed but after a short time frame, it started slowing down. At times, it would do only about 50 to 60MBs/sec. It started out at well over 100MBs/sec which is fairly normal for this rig. I would stop the copy process, let it catch up and restart just to give it some time to process. I can't say it was any faster that way tho. The way I noticed my drive was SMR, I could feel the heads going back and forth by putting my hand on the enclosure. It had a bumpy feel to it. You can't really hear it tho. If you can feel those little bumps even when the drive isn't mounted, I'd be thinking it is a SMR drive. There are also sites that you can look this sort of thing up on too. If needed, I can go dig out some links. Just thought it worth a mention. Dale :-) :-)
