On 07/09/2020 14:36, Hamish McIntyre-Bhatty wrote: > On 24/06/2020 10:18, Hamish McIntyre-Bhatty wrote: >> On 20/06/2020 14:30, Patrick Wigmore wrote: >>> I wonder if it makes a difference what tools you use to unlock and >>> mount the LUKS container and partition. E.g. cryptsetup, mount, >>> udisksctl, some GUI tool (which might depend on udisks2), or something >>> else. >>> >>> The most similar thing I've recently encountered was having a USB >>> flash drive get unmounted and re-enumerated (from /dev/sda to >>> /dev/sdb) during an out-of-memory event (while running ffmpeg on a BT >>> Home Hub). >> Perhaps, I don't know. I use "cryptsetup luksOpen". >> >> Do you check dmesg(1), e.g. ‘dmesg -Hx’ then type ‘-R’, or >> journalctl(1)? >> >> It just happened again and I checked both - nothing to see about the >> device. That's why I started looking in /var/log/messages as it >> supposedly has more history, but nothing there either. >> >> Hamish > I have some new information. I've since bought a powered hub to solve > the power problem (I confirmed there was one), and it has been better > for a while until now. The other day I turned of ufw firewall logging to > keep dmesg clear so I can see what happens. I found this had happened: > > 983261.923799] ------------[ cut here ]------------ > [983261.923836] NETDEV WATCHDOG: enxb827eb7194f1 (lan78xx): transmit > queue 0 timed out > [983261.923915] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:466 > dev_watchdog+0x2b0/0x2b8 > [983261.923919] Modules linked in: xt_recent dm_crypt aes_neon_bs > aes_neon_blk crypto_simd cryptd aes_arm64 algif_skcipher af_alg 8021q > garp stp llc dm_mod brcmfmac brcmutil sg cfg80211 joydev evdev > bcm2835_codec(C) bcm2835_v4l2(C) rfkill v4l2_mem2mem > bcm2835_mmal_vchiq(C) v4l2_common videobuf2_vmalloc videobuf2_dma_contig > videobuf2_memops videobuf2_v4l2 videobuf2_common videodev > raspberrypi_hwmon media hwmon vc_sm_cma(C) uio_pdrv_genirq uio > nf_log_ipv6 ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt > nf_log_ipv4 nf_log_common ipt_REJECT nf_reject_ipv4 xt_multiport xt_LOG > nft_limit xt_limit xt_addrtype xt_tcpudp xt_conntrack nft_compat > nft_counter nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp > nf_nat nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 > nf_tables nfnetlink i2c_dev > [983261.924031] ip_tables x_tables ipv6 > [983261.924051] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G > C 4.19.118-v8+ #1311 > [983261.924056] Hardware name: Raspberry Pi 3 Model B Plus Rev 1.3 (DT) > [983261.924061] pstate: 80000005 (Nzcv daif -PAN -UAO) > [983261.924067] pc : dev_watchdog+0x2b0/0x2b8 > [983261.924071] lr : dev_watchdog+0x2b0/0x2b8 > [983261.924074] sp : ffffff8008013d70 > [983261.924077] x29: ffffff8008013d70 x28: ffffffc03c59ba00 > [983261.924083] x27: ffffff8008cc5000 x26: 0000000000000140 > [983261.924090] x25: 00000000ffffffff x24: ffffffc03b24d480 > [983261.924102] x23: ffffffc03b24d45c x22: ffffffc03b306280 > [983261.924114] x21: ffffff8008cc6000 x20: ffffffc03b24d000 > [983261.924119] x19: 0000000000000000 x18: ffffff8008cc8688 > [983261.924125] x17: 0000000000000000 x16: 0000000000000000 > [983261.924130] x15: ffffff8008df8e78 x14: 74756f2064656d69 > [983261.924135] x13: 7420302065756575 x12: 712074696d736e61 > [983261.924140] x11: 7274203a29787838 x10: 0000000000000000 > [983261.924145] x9 : 0000000000016644 x8 : 0000000000000000 > [983261.924150] x7 : ffffff8008cc8688 x6 : ffffffc03e5a20a0 > [983261.924155] x5 : 0000000000000000 x4 : fffffffffffffff8 > [983261.924160] x3 : 0000000000000000 x2 : 0000000000000004 > [983261.924167] x1 : f1fa254012d51300 x0 : 0000000000000000 > [983261.924179] Call trace: > [983261.924187] dev_watchdog+0x2b0/0x2b8 > [983261.924199] call_timer_fn+0x34/0x1c8 > [983261.924207] expire_timers+0xbc/0x150 > [983261.924215] run_timer_softirq+0xb4/0x1a8 > [983261.924224] __do_softirq+0x17c/0x3cc > [983261.924232] irq_exit+0xe8/0xf8 > [983261.924238] __handle_domain_irq+0x90/0x100 > [983261.924243] bcm2836_arm_irqchip_handle_irq+0x68/0xd8 > [983261.924248] el1_irq+0xb4/0x130 > [983261.924254] arch_cpu_idle+0x30/0x1f0 > [983261.924260] default_idle_call+0x24/0x40 > [983261.924265] do_idle+0x224/0x240 > [983261.924270] cpu_startup_entry+0x28/0x30 > [983261.924276] secondary_start_kernel+0x188/0x1d8 > [983261.924280] ---[ end trace b2a07353fff8d125 ]--- > > Hopefully the list won't clobber that but I'll try an attachment if it > does. Looks like a kernel oops? Even though the volume has the > "errors=remount-rw" option, it still unmounts completely when this > happens. Good news is no I/O errors so the disk is okay at least. > > Any ideas on how I might further debug this? > > Hamish
NB: Turns out my auto update script failed a few weeks back, and I'll now have kernel 5.4 - might be worth seeing if it happens again before spending time trying to debug. Might also be cos I'm running the kernel in 64-bit mode for distributed computing, not sure if that's something that is supported. Hamish
signature.asc
Description: OpenPGP digital signature
-- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
