Сайт minetest.net не открывается на билайне
Такая проблема:
При попытке открыть сайт minetest.net через данного оператора, он не открывается, а браузер возвращает ошибку «Время ожидания соединения истекло».
Неужели блокировка?
Сообщения ne-vlezay
Скрипт для кроссировки сетевых интерфейсов виртуальных машин
Сам скрипт: (для распоковки скопировать и сделать cat switch1.txt|base64 -d|tar -xvfz -)
H4sIAAAAAAAAA+1XX2/jNgzvq/UpWMe4NDi0sdOmHXIwbrvtBuxpWPfYFYXOVhoDjt2zlLZb2332
UX9sy7Hb5g44bAPEh8SiqR8pkiJpfpeJZDU74qu9b0Yh0tl8rv6Rtv/PZmfHe9HJaTiLZmF4fLYX
RtE8nO1B+O1MamnDBa0A9qqyFC/Jvfb+f0qj/emnrJh+onxFSMqSnFYMDimsKRes4jaL5/SWcUIT
kZVFHESE5CVNr1Iq6MEEHoiXlwnN4Zeff4+D8R/FuGbkWcFIvVjRIs1ZvcqWBV03q9ssrR9p85A0
MAWCZEu4uIB9OFyCLxgXabk+EvfCh8vLdyBWrCCeVzGxqQqIiLfMcMuyrJQJkBUQHCRUgLVx8g7S
Evdo3EDJxX/DeDS2Eb2kLERWbNBSjdk5KuBJPZrEoXyLyqjSJKEMeI1OE4hjCDvInnZIHFC50uBd
+agrr132gvysK49ObYU9ZWhwcBA80OTpbTSZeMhLy4I1Pjj8CwJtE+LA42PN03q7PMTuKDOePyVG
mbFLivUObhLsbewbdYtahd/dvv8MgE7H/v6FEm9ANgVnQkaKmHO2jCeCKUwrkVytaUGv2VW1yZmd
ypjqMs/NipebKmHZMg5mNSvFTKoDeGwz6yidNLmd00JGYt6gfc44u8+4iBsFaZ+FxUmw+BSjPGLJ
qoQfFhhlAR8WQW0N/LgIWjPgJ70yrvyIzlCKcb8JTkisQFsbO4G1IDr8Rmk3DZSKgSt4aq6gdWun
/E8+xZLC+bRgYho81JBPU5qmFeN8AOdkB5zW5NeRwHLBgUjgc5rxBPiqvMPg3VrHNL5ZIi0mFhwo
8toYhgQMLTPzFsgrWiwn9/XUdqe2CtsLKg/wUvgVW5e3TFZAePNGvWnM6pWPxoqU5dqI1v9wg3W+
ENoIlNWpF7wnO2pNv0SrFa2v1dur96HaUW/oOCEcNAfTpOcEOxJYx69lHm0bVatIv0SFfeJnlOCu
ZZZjVXxmm+0oSFYU20wENxVbwul8fjzHx1KUSYl1K8+xgeNcJx90v4a0Km/63h1Q2SR/R50x2a4Y
jbrvwtlR9Bss8/IOgWQ1uMJyUJcFo1+u4Ka8qdfrrKpYCkwdHvAxqxjGePtmEMviAWMtyZ3NHfKO
tm7DV9C3/Br31e7+SnM6wYp2cea2gV13yRVOGt14tUNKYyOpL0egWLLjZQU+5nmv162blkO8hqd6
dHdk07zu4KZacVdMsQakrBlPI0mG3W99Y6DfXLPouYuvxA3fGvbWav56MAPGxfeXT2YOs4+DQ5Bq
qMH6MdkIOExhvBhjY4kmjWDdw4cFZxNi5j2u9el5xFLnWW5pUPiAOs9y1nOCs1ZQTXTDUsdKaoR5
eQ/S8Tiobs834Mta6uOffUq5tsxtlltvUbVvDZzvVanfGmitWVlPYHrsUr84hrzgsdGuHhvt6DEp
+VJGjHbPidHOWSFF6wh4nlq+EIQtL9vm9GMUtFcGYbVfR9qxeLPXWGP0jdbhUTqwdvjq/shvtc7t
aT7e5KRtFYW2o2714C7eptgZEfQdHQBWPvQ/np//er4wlY6DhHk08KT9mjMnJARbrpAQ//ansyNH
jhw5cuTIkSNHjhw5cuTIkSNHjhw5cvSfpX8AkiRgGwAoAAA=
Дальше создать конфиг в формате:
vm-switch0.1 0
vm-switch0.2 0
vm-ppp0.0 2
vm-border0.0 3
В первой колонке имя интервейса виртуальной машины а во второй vlan id
(многое в скрипте не реализовано)
Постоянные ошибки в файловой системе
Имеется VPS, на которой периодически файловая система может монтироваться в RO (Read Only). В логах я нашёл:
Filesystem error recorded from previous mount: IO failure
Началось это после того, как восстановил VPS из резервной копии.
Интересно, это ли баг qemu, или же проблема с оборудованием, что где-то там у хостера.
alpine linux перестали работать контейнеры
После сегодняшнего обновления, перестали запускаться контейнеры. Вот лог:
lxc gw 20230806072313.419 ERROR conf - ../src/lxc/conf.c:lxc_map_ids:3701 - newuidmap failed to write mapping "newuidmap: Target process 3137 is owned by a different user: uid:0 pw_uid:0 st_uid": newuidmap 3137 0 100000 65536
lxc gw 20230806072313.419 ERROR start - ../src/lxc/start.c:lxc_spawn:1788 - Failed to set up id mapping.
lxc gw 20230806072313.419 ERROR lxccontainer - ../src/lxc/lxccontainer.c:wait_on_daemonized_start:878 - Received container state "ABORTING" instead of "RUNNING"
lxc gw 20230806072313.421 ERROR start - ../src/lxc/start.c:__lxc_start:2107 - Failed to spawn container "gw"
lxc gw 20230806072313.421 WARN start - ../src/lxc/start.c:lxc_abort:1036 - No such process - Failed to send SIGKILL via pidfd 45 for process 3137
lxc 20230806072318.542 ERROR af_unix - ../src/lxc/af_unix.c:lxc_abstract_unix_recv_fds_iov:218 - Connection reset by peer - Failed to receive response
lxc 20230806072318.542 ERROR commands - ../src/lxc/commands.c:lxc_cmd_rsp_recv_fds:128 - Failed to receive file descriptors for command "get_state"
Дистрибутив у меня: alpine linux 3.18
frrouting не собирается под archlinux
gcc: warning: /usr/include/libyang: linker input file unused because linking not done
CC tools/gen_northbound_callbacks.o
gcc: warning: /usr/include/libyang: linker input file unused because linking not done
CC tools/gen_yang_deviations.o
gcc: warning: /usr/include/libyang: linker input file unused because linking not done
CC bgpd/bgp_btoa.o
gcc: warning: /usr/include/libyang: linker input file unused because linking not done
gcc: warning: /usr/include/libyang: linker input file unused because linking not done
CC ospfclient/ospfclient.o
gcc: warning: /usr/include/libyang: linker input file unused because linking not done
CCLD tools/ssd
/usr/bin/ld: error: /usr/include/libyang: read: Is a directory
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:8955: tools/ssd] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/user/1/frr'
make: *** [Makefile:6252: all] Error 2
В интернете естественно проблем нет.
Проблема с жёстким диском
У меня имеется гипервизор, на котором у меня запускаются виртуальные машины. Недавно все виртуальные машины начали тормазить или же вообще выводить ошибку ввода/вывода.
В логах при этом на самом гипервизоре:
[ 3737.169514] blk_update_request: I/O error, dev sdc, sector 692530183
[ 3737.169519] Buffer I/O error on dev sdc, logical block 86566272, async page read
[ 3737.169537] ata7: EH complete
[ 3739.437775] ata7.00: exception Emask 0x0 SAct 0x20 SErr 0x0 action 0x0
[ 3739.437781] ata7.00: irq_stat 0x40000008
[ 3739.437787] ata7.00: failed command: READ FPDMA QUEUED
[ 3739.437799] ata7.00: cmd 60/08:28:00:2c:47/00:00:29:00:00/40 tag 5 ncq dma 4096 in
res 41/40:00:07:2c:47/00:00:29:00:00/40 Emask 0x409 (media error) <F>
[ 3739.437805] ata7.00: status: { DRDY ERR }
[ 3739.437809] ata7.00: error: { UNC }
[ 3739.447097] ata7.00: configured for UDMA/133
[ 3739.447114] sd 6:0:0:0: [sdc] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 3739.447118] sd 6:0:0:0: [sdc] tag#5 Sense Key : Medium Error [current]
[ 3739.447123] sd 6:0:0:0: [sdc] tag#5 Add. Sense: Unrecovered read error - auto reallocate failed
[ 3739.447127] sd 6:0:0:0: [sdc] tag#5 CDB: Read(10) 28 00 29 47 2c 00 00 00 08 00
[ 3739.447130] blk_update_request: I/O error, dev sdc, sector 692530183
[ 3739.447136] Buffer I/O error on dev sdc, logical block 86566272, async page read
[ 3739.447154] ata7: EH complete
Что это и как это исправить?
nftables: фильтрация на канальном уровне
Пытаюсь сделать:
nft add rule bridge bridge_filter vlan2 arp saddr ether arp saddr ip map {0a:e8:a4:24:20:e1 : 192.168.1.1}
Получаю:
Error: syntax error, unexpected map, expecting end of file or newline or semicolon
Что не так?
В archlinux виртуализацию KVM сломали
https://bugzilla.kernel.org/show_bug.cgi?id=216017
При попытке запустить виртуальною машину, периодически возникает:
[root@router ne-vlezay80]# qemu-system-x86_64 -enable-kvm
qemu-system-x86_64: error: failed to set MSR 0xc0000104 to 0x100000000
qemu-system-x86_64: ../qemu-7.0.0/target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
Также система может уйти в kernel panic, если виртуальная машина будет запущена через некоторое время.
Процессор: AMD Phenom X4
Странности с локальным DNS
Прописываю обратную зону для своих хостов.
Работает через раз.
Когда не работает, в tcpdump наблюдаю:
15:11:51.687943 00:16:3e:42:81:9f > a2:b7:40:1d:a1:44, ethertype IPv6 (0x86dd), length 133: 2a01:d0:xx:82::1:4.39230 > 2a01:d0:xx:82:1::4.53: 38971% [1au] PTR? 33.myvpn.2.18.172.in-addr.arpa. (71)
15:11:53.291341 00:16:3e:42:81:9f > a2:b7:40:1d:a1:44, ethertype IPv6 (0x86dd), length 133: 2a01:d0:xx:82::1:4.38818 > 2a01:d0:xx:82:1::4.53: 17701% [1au] PTR? 33.myvpn.2.18.172.in-addr.arpa. (71)
15:11:56.494670 00:16:3e:42:81:9f > a2:b7:40:1d:a1:44, ethertype IPv6 (0x86dd), length 133: 2a01:d0:xx:82::1:4.52595 > 2a01:d0:xx:82:1::4.53: 84% [1au] PTR? 33.myvpn.2.18.172.in-addr.arpa. (71)
Что это?
Что случилось с netassist?
Где-то 14:00 у туннельного брокера netassist начались проблемы со связонностью. Потом через брокер вообще перестал работать ipv6. Также через некоторых аплинков наблюдается петля на сайт netassist.ua.
Вот трассировка до ya.ru через netassist:
[0]ne-vlezay80@ne-vlezay80:~$ traceroute -6 ya.ru
traceroute to ya.ru (2a02:6b8::2:242), 30 hops max, 80 byte packets
1 2002::2 (2002::2) 0.061 ms 0.029 ms 0.028 ms
2 2a01:d0:c353:82::1 (2a01:d0:c353:82::1) 0.548 ms 0.548 ms 0.587 ms
3 2a01:d0:c353:1:: (2a01:d0:c353:1::) 71.743 ms 71.918 ms 65.690 ms
4 4xe0-778.APOLLO.iev.ua.29632.as (2a01:d0:0:1c::44) 106.431 ms 108.843 ms 106.457 ms
5 2a01:d0:0:1c::144 (2a01:d0:0:1c::144) 117.413 ms 120.068 ms 117.290 ms
6 * * *
Вот трассировка до netassist.ua через один из сервисов:
traceroute to netassist.ua (2001:67c:1874:7::2), 30 hops max, 80 byte packets
1 2001:2e8:665:0:2:2:0:1 (2001:2e8:665:0:2:2:0:1) 0.106 ms 0.064 ms 0.065 ms
2 2001:2e8:22:204::2 (2001:2e8:22:204::2) 0.997 ms 1.068 ms 1.110 ms
3 2001:2e8:20::22:11 (2001:2e8:20::22:11) 1.667 ms 1.531 ms 1.555 ms
4 xe-0-0-10-1.a02.tokyjp05.jp.bb.gin.ntt.net (2001:218:2000:5000::655) 2.271 ms xe-0-0-15-0.a02.tokyjp05.jp.bb.gin.ntt.net (2001:218:2000:5000::665) 2.051 ms xe-0-0-11-1.a02.tokyjp05.jp.bb.gin.ntt.net (2001:218:2000:5000::659) 1.838 ms
5 ae-25.r02.tokyjp05.jp.bb.gin.ntt.net (2001:218:0:2000::59) 2.053 ms ae-4.r03.tokyjp05.jp.bb.gin.ntt.net (2001:218:0:2000::95) 1.885 ms 2.168 ms
6 ae-3.r31.tokyjp05.jp.bb.gin.ntt.net (2001:218:0:2000::116) 1.581 ms 1.453 ms ae-4.r31.tokyjp05.jp.bb.gin.ntt.net (2001:218:0:2000::122) 1.604 ms
7 * * *
8 ae-5.r25.asbnva02.us.bb.gin.ntt.net (2001:418:0:2000::1bd) 165.104 ms 172.455 ms 160.172 ms
9 ae-7.r21.londen12.uk.bb.gin.ntt.net (2001:418:0:2000::5d) 251.179 ms 251.013 ms 250.917 ms
10 ae-16.r20.frnkge13.de.bb.gin.ntt.net (2001:728:0:2000::15e) 258.055 ms 257.017 ms 257.465 ms
11 ae-2.a00.frnkge13.de.bb.gin.ntt.net (2001:728:0:2000::25a) 271.634 ms 271.505 ms 266.665 ms
12 xe-0-0-19-2-276.a00.frnkge13.de.ce.gin.ntt.net (2001:728:0:5000::15eb) 251.029 ms 250.353 ms 250.898 ms
13 2001:67c:1874:313::2 (2001:67c:1874:313::2) 249.704 ms 249.831 ms 250.909 ms
14 2001:67c:1874:313::1 (2001:67c:1874:313::1) 244.812 ms 244.291 ms 239.524 ms
15 2001:67c:1874:313::2 (2001:67c:1874:313::2) 245.398 ms 244.959 ms 244.050 ms
16 2001:67c:1874:313::1 (2001:67c:1874:313::1) 238.417 ms 252.687 ms 252.154 ms
17 2001:67c:1874:313::2 (2001:67c:1874:313::2) 250.755 ms 243.957 ms 248.657 ms
18 2001:67c:1874:313::1 (2001:67c:1874:313::1) 251.964 ms * *
19 2001:67c:1874:313::2 (2001:67c:1874:313::2) 244.214 ms * 250.275 ms
20 * * *
21 2001:67c:1874:313::2 (2001:67c:1874:313::2) 249.781 ms * 244.683 ms
22 2001:67c:1874:313::1 (2001:67c:1874:313::1) 251.539 ms 240.126 ms *
23 2001:67c:1874:313::2 (2001:67c:1874:313::2) 252.012 ms 245.525 ms 250.006 ms
24 2001:67c:1874:313::1 (2001:67c:1874:313::1) 240.333 ms * 251.160 ms
25 2001:67c:1874:313::2 (2001:67c:1874:313::2) 258.434 ms 251.064 ms 244.601 ms
26 2001:67c:1874:313::1 (2001:67c:1874:313::1) 238.591 ms 253.149 ms 244.956 ms
27 2001:67c:1874:313::2 (2001:67c:1874:313::2) 251.393 ms 250.994 ms 245.737 ms
28 2001:67c:1874:313::1 (2001:67c:1874:313::1) 238.550 ms 239.050 ms *
29 2001:67c:1874:313::2 (2001:67c:1874:313::2) 250.199 ms 258.442 ms 249.149 ms
30 2001:67c:1874:313::1 (2001:67c:1874:313::1) 251.243 ms 244.556 ms 252.305 ms
Что случилось у netassist с протоколом ipv6?
Слетела openbsd
У меня слетела на роутере openbsd.
Вот лог загрузки:
add net 10.0.0.0/8: gateway 192.168.181.3
fd0 at fdc0 drive 1: density unknown
reordering libraries: done.
starting early daemons: syslogd pflogd nsd unbound ntpd.
starting RPC daemons:.
savecore: /dev/wd0a: Device not configured
kernel: protection fault trap, code=0
Stopped at copyout+0x53: repe movsq (%rsi),%es:(%rdi)
ddb> set $lines = 0
ddb> set $maxwidth = 0
ddb> show panic
the kernel did not panic
ddb> show trace
No such command
ddb> trace
copyout(2000000000000000,3c,ffff800011edaa08,2000000000000000,4035ae18e9ac3078,1) at copyout+0x53
mmrw(201,ffff800011edaa08,0) at mmrw+0x1b1
spec_read(ffff800011eda8a8) at spec_read+0xa7
VOP_READ(fffffd8027585840,ffff800011edaa08,0,fffffd80317a8de0) at VOP_READ+0x41
vn_read(fffffd802240fbd0,ffff800011edaa08,1) at vn_read+0xa1
dofilereadv(ffff8000ffff4500,5,ffff800011edaa08,1,ffff800011edaae0) at dofilereadv+0xf6
sys_pread(ffff8000ffff4500,ffff800011edaa88,ffff800011edaae0) at sys_pread+0x5c
syscall(ffff800011edab50) at syscall+0x315
Xsyscall(6,c6,2000000000000000,c6,5,1c64e42625c0) at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7ffffd1d90, count: -9
ddb>
Что здесь не так.
Работал он почти два года и вот.
Сыпится файловая система
Привет, такая проблема. Есть компьютер, который используется как роутер а также контейнерный сервер. В логах у него такое:
848.648139] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 18, gen 0
[ 849.141432] BTRFS warning (device sda2): checksum error at logical 12112596992 on dev /dev/sda2, physical 12112596992, root 290, inode 2153392, offset 4214378496, length 4096, links 1 (path: var/lib/lxd/disks/default.img)
[ 849.141465] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 19, gen 0
[ 849.195020] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 20, gen 0
[ 852.190183] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 21, gen 0
[ 866.312699] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 22, gen 0
[ 870.094738] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 23, gen 0
[ 874.623532] BTRFS info (device sda2): scrub: not finished on devid 1 with status: -125
[ 915.548043] BTRFS info (device sda2): scrub: started on devid 1
[ 926.183099] kauditd_printk_skb: 14 callbacks suppressed
[ 926.183110] audit: type=1130 audit(1642170476.243:210): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 926.183129] audit: type=1131 audit(1642170476.243:211): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 963.509864] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 24, gen 0
[ 964.184943] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 25, gen 0
[ 964.414589] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 26, gen 0
[ 966.260093] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 27, gen 0
[ 966.619578] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 28, gen 0
[ 967.107493] BTRFS warning (device sda2): checksum error at logical 12112596992 on dev /dev/sda2, physical 12112596992, root 290, inode 2153392, offset 4214378496, length 4096, links 1 (path: var/lib/lxd/disks/default.img)
[ 967.107505] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 29, gen 0
[ 967.165297] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 30, gen 0
[ 970.167824] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 31, gen 0
[ 984.112427] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 32, gen 0
[ 987.712951] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 33, gen 0
[ 1018.115785] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 34, gen 0
[ 1018.144848] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 35, gen 0
[ 1019.375785] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 36, gen 0
[ 1019.527438] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 37, gen 0
[ 1025.579311] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 38, gen 0
[ 1038.929269] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 39, gen 0
[ 1042.125975] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 40, gen 0
[ 1043.770749] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, flush 0, corrupt 41, gen 0
На других дисках с btrfs всё вроде-бы нормально. Причём corrupt каждый раз увеличивается. Проблема наблюдается только с тем диском, на котором стоит операционная система. Это ssd.
Ядро: 5.15.11-arch2-1
Тут различные варианты - от самого плохого(летит ssd и рано или поздно либо уйдёт в ro или же вообще перестанет опредилятся) от бага в ядре, который связан с повреждением данных.
tc-flower не видет 6to4 пакеты
Решил настроить антиспуфинг через tc при помощи tc-flower, в результате стали поступать жалобы о том, что люди не могут к туннельном брокерам ipv6 подключится. Когда начали разбираться, то поняли, что проблема в tc-flower. Вот пример конфигурации:
switch@blackmesa1 #> tc -s filter show dev sw0p50 parent ffff:
filter protocol ip pref 1 flower chain 0
filter protocol ip pref 1 flower chain 0 handle 0x1
eth_type ipv4
src_ip 198.18.250.110
not_in_hw
action order 1: gact action pass
random type none pass val 0
index 2 ref 1 bind 1 installed 640 sec used 640 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
filter protocol ip pref 65535 matchall chain 0
filter protocol ip pref 65535 matchall chain 0 handle 0x1
not_in_hw (rule hit 1138)
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1 installed 1162 sec used 0 sec firstused 1161 sec
Action statistics:
Sent 141112 bytes 1138 pkt (dropped 1138, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Когда переделал на tc-u32 - всё стало работать нормально.
Восстановление файловой системы с BTRFS после аппаратного сбоя хоста
Такая проблема:
Имеется виртуальная машина на которой запущенны контейнеры. Один раз отволился на хостовой машине коннектор питания от жёсткого диска. После этого теперь файловая система с этим контейнером уходит в read only. При попытке исправить файловую систему возникает:
root@lxd-two:/var/snap/lxd/common/lxd/disks# btrfs check --repair ./default.img
enabling repair mode
Opening filesystem to check...
warning, bad space info total_bytes 2147483648 used 2147725312
Checking filesystem on ./default.img
UUID: 5b91b327-bce3-4e45-a7ee-86fa0a774573
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
ref mismatch on [3582070784 94208] extent item 0, found 1
data backref 3582070784 root 438 owner 559207 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582070784 root 438 owner 559207 offset 0 found 1 wanted 0 back 0x55b659277050
backpointer mismatch on [3582070784 94208]
repair deleting extent record: key [3582070784,168,241664]
adding new data backref on 3582070784 root 438 owner 559207 offset 0 found 1
Repaired extent references for 3582070784
ref mismatch on [3582164992 114688] extent item 0, found 1
data backref 3582164992 root 516 owner 18532 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582164992 root 516 owner 18532 offset 0 found 1 wanted 0 back 0x55b6790b4a20
backpointer mismatch on [3582164992 114688]
adding new data backref on 3582164992 root 516 owner 18532 offset 0 found 1
Repaired extent references for 3582164992
ref mismatch on [3582279680 12288] extent item 0, found 1
data backref 3582279680 root 516 owner 18591 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582279680 root 516 owner 18591 offset 0 found 1 wanted 0 back 0x55b67ac215c0
backpointer mismatch on [3582279680 12288]
adding new data backref on 3582279680 root 516 owner 18591 offset 0 found 1
Repaired extent references for 3582279680
ref mismatch on [3582291968 12288] extent item 0, found 1
data backref 3582291968 root 542 owner 61178 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582291968 root 542 owner 61178 offset 0 found 1 wanted 0 back 0x55b67b4e5b90
backpointer mismatch on [3582291968 12288]
adding new data backref on 3582291968 root 542 owner 61178 offset 0 found 1
Repaired extent references for 3582291968
ref mismatch on [3582304256 8192] extent item 0, found 1
data backref 3582304256 root 542 owner 61287 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582304256 root 542 owner 61287 offset 0 found 1 wanted 0 back 0x55b67ad842d0
backpointer mismatch on [3582304256 8192]
adding new data backref on 3582304256 root 542 owner 61287 offset 0 found 1
Repaired extent references for 3582304256
Failed to find [29638656, 168, 16384]
btrfs unable to find ref byte nr 29720576 parent 0 root 2 owner 0 offset 0
transaction.c:195: btrfs_commit_transaction: BUG_ON `ret` triggered, value -5
btrfs(+0x3b748)[0x55b6539de748]
btrfs(btrfs_commit_transaction+0x12a)[0x55b6539debcc]
btrfs(+0x55861)[0x55b6539f8861]
btrfs(cmd_check+0x1288)[0x55b6539f9e75]
btrfs(main+0x1f3)[0x55b6539b6e63]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f08f464409b]
btrfs(_start+0x2a)[0x55b6539b6eaa]
Aborted
Как теперь исправить файловую систему?
Плохо работает вложенная виртуализация (Nested virtualization)
Ядро на хосте:
4.19.188-amd64-cust1
Ядро в виртуальной машине: 5.10+, 5.11+
Версия qemu: 2.8.1
Система: Devuan Ascii
Проблема:
Если пытаться использовать вложенную виртуализацию и на ней запустить linux или openbsd, то система внутри вложенной виртуальной машине периодически зависает. Если смотреть strace, то во время зависания там много timeout’ов. Но, если на хосте использовать ядро от 5.10+ и qemu 5.20, то всё нормально. Вложенная виртуализация (nested virtualization) работает нормально.
Странности с FRRouting
Добрей день, если компилировать его с параметрами:
./configure --prefix=/usr --includedir=\${prefix}/include --enable-exampledir=\${prefix}/share/doc/frr/examples --bindir=\${prefix}/bin --sbindir=\${prefix}/lib/frr --libdir=\${prefix}/lib/frr --libexecdir=\${prefix}/lib/frr --localstatedir=/var/run/frr --sysconfdir=/etc/frr --with-moduledir=\${prefix}/lib/frr/modules --with-libyang-pluginsdir=\${prefix}/lib/frr/libyang_plugins --enable-configfile-mask=0640 --enable-logfile-mask=0640 --enable-snmp=agentx --enable-multipath=64 --enable-user=frr --enable-group=frr --enable-vty-group=frrvty --with-pkg-git-version --with-pkg-extra-version=-MyOwnFRRVersion --enable-systemd
То, если выполнить
show ip ospf interface lo
ospfd вылетает по sigabrt.
В логах при этом:
пр 22 18:38:53 archlinux OSPF[119617]: Received signal 6 at 1619105933 (si_addr 0xb10001d341, PC 0x7f769cd8cef5); aborting...
апр 22 18:38:53 archlinux OSPF[119617]: zlog_signal+0xf5 7f769d3bd205 7ffd2b60c9f0 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: core_handler+0xb1 7f769d3e6851 7ffd2b60cb30 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: funlockfile+0x60 7f769cf33960 7ffd2b60cc80 /usr/lib/libpthread.so.0 (mapped at 0x7f769cf20000)
апр 22 18:38:53 archlinux OSPF[119617]: ---- signal ----
апр 22 18:38:53 archlinux OSPF[119617]: gsignal+0x145 7f769cd8cef5 7ffd2b60d220 /usr/lib/libc.so.6 (mapped at 0x7f769cd50000)
апр 22 18:38:53 archlinux OSPF[119617]: abort+0x116 7f769cd76862 7ffd2b60d340 /usr/lib/libc.so.6 (mapped at 0x7f769cd50000)
апр 22 18:38:53 archlinux OSPF[119617]: __assert_fail_base.cold+0xf 7f769cd76747 7ffd2b60d470 /usr/lib/libc.so.6 (mapped at 0x7f769cd50000)
апр 22 18:38:53 archlinux OSPF[119617]: __assert_fail+0x46 7f769cd85646 7ffd2b60d4c0 /usr/lib/libc.so.6 (mapped at 0x7f769cd50000)
апр 22 18:38:53 archlinux OSPF[119617]: route_node_delete+0x1da 7f769d3f24fa 7ffd2b60d4f0 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: route_next+0x69 7f769d3f2579 7ffd2b60d520 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: show_ip_ospf_interface_sub+0x5e8 558bfb49dd18 7ffd2b60d540 /usr/lib/frr/ospfd (mapped at 0x558bfb3f1000)
апр 22 18:38:53 archlinux OSPF[119617]: show_ip_ospf_interface_common+0x1bb 558bfb49ea0b 7ffd2b60d620 /usr/lib/frr/ospfd (mapped at 0x558bfb3f1000)
апр 22 18:38:53 archlinux OSPF[119617]: show_ip_ospf_interface+0x24a 558bfb49ed9a 7ffd2b60d690 /usr/lib/frr/ospfd (mapped at 0x558bfb3f1000)
апр 22 18:38:53 archlinux OSPF[119617]: cmd_execute_command_real.constprop.0+0x138 7f769d390818 7ffd2b60d6f0 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: cmd_execute_command+0x54 7f769d392174 7ffd2b60d760 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: cmd_execute+0xd0 7f769d3923b0 7ffd2b60d7b0 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: vty_command+0x14d 7f769d3fce6d 7ffd2b60d810 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: vty_execute+0x31 7f769d3fd561 7ffd2b60f9b0 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: vtysh_read+0xc0 7f769d4001f0 7ffd2b60f9f0 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: thread_call+0xf3 7f769d3f7553 7ffd2b60fc40 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: frr_run+0xe0 7f769d3b5ec0 7ffd2b60fde0 /usr/lib/frr/libfrr.so.0 (mapped at 0x7f769d330000)
апр 22 18:38:53 archlinux OSPF[119617]: main+0x148 558bfb454058 7ffd2b610010 /usr/lib/frr/ospfd (mapped at 0x558bfb3f1000)
апр 22 18:38:53 archlinux OSPF[119617]: __libc_start_main+0xd5 7f769cd77b25 7ffd2b610030 /usr/lib/libc.so.6 (mapped at 0x7f769cd50000)
апр 22 18:38:53 archlinux OSPF[119617]: _start+0x2e 558bfb45489e 7ffd2b610100 /usr/lib/frr/ospfd (mapped at 0x558bfb3f1000)
апр 22 18:38:53 archlinux OSPF[119617]: in thread vtysh_read scheduled from lib/vty.c:2682 vty_event()
Самое интересное то, что когда я указал с переменной:
CFLAGS="-O1"
то всё работало нормально.
Но, когда я разогнал процессор до 4.5Gz, то даже без параметров всё компилировалось и работало нормально. Как это может влиять - не знаю.
Надо как-то попробывать его скомпилировать на других машинах. Вполне возможно, что этот баг повторяется только на моём компьютере.
Процессор у меня: AMD FX 6300.
Как может повлиять на программное обеспечения инцедент со Столлманом?
Такой вопрос:
Некоторые пишут, что примут некую GPLv4, другие пишут, что Linux закроет исходный код, другие вообще призывают распустить debian.
- Моё мнение по поводу закрытия исходников linux, см в этой теме
- В этом видео вообще говорят о том, что все дистрибутивы станут платными
Такой вопрос, чем может закончится вся эта история?
Что нас ждёт в GPLv4?
В связи с последними событиями в фонде СПО, когда им завладеют корпорации, выпустить некую лицензию, которая типо может позволить закрыть чуть ли не весь открытый исходный код.
Прошло больше суток. Подведём итоги.
- Деда так и не спасли.
- GPL под угрозой, на горизонте GPLv4 с открытием исходников через 25 лет.
- Fedora GNU/Linux трансформировалась в Fedora Linux и стала настоящей Pidora.
- Red Hat яйцами, помидорами, вибраторами, вагинами незакидана.
- Подписавшие против деда не удалили весь GNU софт и софт с GPL лицензией.
Возможность в будущем выпустить GPLv4 в которой может быть прописано все, что угодно и она будет применима к проектам GPLv2+ и GPLv3+, которые не смогут уговорить всех авторов перелицензироваться.
Помнится, об этом ещё Linus предупреждал в перепалке об использовании лицензии GPL текущей версии vs GPL+. Получает кто-то управление над GNU и меняет текст и версию лицензии на свою. И весь софт под GPL+ в шляпе (може даже в красной). GPL+ удобна, но это как чистый бланк с печатью и подписью.
Надеюсь, что не за это наезд идёт…
И так далее.
Как я считаю, исходный код в новой GPLv4 закрывать никто не будет, максимум что может случится, это оттуда уберут copyleft, и то, врядли. Потому, что:
- Исходный код закрывать не выгодна даже для самих корпораций. (Если исходный код открыт, в разработке может принимать участие неограниченный круг лиц, а если закрыт, то только сотрудники самой корпорации.)
- Закрывать и открывать код можно было и раньше, просто лицензируешь под EULA а потом ставить открытую или свободную лицензию.
кроме того, все новые версии лицензии должны соответствовать по духу предыдущих.
Что случится, если фондом СПО завладеют корпорации?
Я где-то слышал, что Armacham Teсhnology Corporation решила завладеть фондом СПО, а Женевьеву Аристид назначить директорам этого фонда. Меня интерисует, что может случится с linux в этом случае. Может ли linux закрыть исходный код и стать платным в результате этого?
Системя зависает на ровном месте
Такая проблема:
Если система сильно загружена, то при использовании opengl приложений, система зависает. Также может пропасть сеть.
В логах и на консоле в это время если удасться подключиться: bug nvi soft lookup.
Ядро: 4.9.0-15-amd64 Система: Devuan Ascii
| следующие → |