Message-ID: <51a1939c-2a99-e86a-1799-c31248e21d89@molgen.mpg.de>
Date:   Sat, 5 Dec 2020 20:34:34 +0100
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Andreas Dilger <adilger.kernel@...ger.ca>,
        linux-ext4@...r.kernel.org, Colin Watson <cjwatson@...ian.org>
Subject: Re: ext4: Funny characters appended to file names

[Cc: +Colin]

Dear Ted,


Am 04.12.20 um 19:05 schrieb Theodore Y. Ts'o:
> On Fri, Dec 04, 2020 at 04:39:12PM +0100, Paul Menzel wrote:

Colin, the modules in `/boot/grub/i386-pc` look funny, and can’t be 
loaded by GRUB anymore.

```
$ ls -lt /boot/grub/i386-pc/
insgesamt 2085
-rw-r--r-- 1 root root    512 13. Aug 23:00 'boot.img-'$'\205\300''u'$' 
\023\211''鍓]'$'\206\371\377\211\360\350''f'$'\376\377\377\205 
\300''ur'$'\203\354\004''V'$'\377''t$'$'\030''j'$'\002''胒'
-rw-r--r-- 1 root root  30893 13. Aug 23:00 'core.img-'$'\205\300''u'$' 
\023\211''鍓]'$'\206\371\377\211\360\350''f'$'\376\377\377\205 
\300''ur'$'\203\354\004''V'$'\377''t$'$'\030''j'$'\002''胒'
[…]
```

>>> $ sudo LANG=C fsck.ext4 -f /dev/md0
>>> e2fsck 1.45.6 (20-Mar-2020)
>>> Pass 1: Checking inodes, blocks, and sizes
>>> Pass 2: Checking directory structure
>>> Pass 3: Checking directory connectivity
>>> Pass 4: Checking reference counts
>>> Pass 5: Checking group summary information
>>> boot: 327/124928 files (17.7% non-contiguous), 126021/497856 blocks
>>
>> I can’t remember if that was an Ext2 or Ext3 when created several years ago.
> 
> Well, the output dumpe2fs will tell us an awful lot about the file
> system.

Interesting. The file system was created in 2008. ;-) Please find the 
dumpe2fs output attached.

> When was the last time the directory was OK?  Do you know when it may
> have gotten corrupted?

The last reboot before. But I am really confused now though.

     $ ls -ld /boot/grub/i386-pc
     drwxr-xr-x 2 root root 28672 29. Nov 12:13 /boot/grub/i386-pc

But the module files in there are all from August 2020.

     -rw-r--r-- 1 root root   2400 Aug 13 23:00 
'part_gpt.mod-'$'\205\300''u'$'\023\211\351\215\223'']'$'\206\371\377\211\360\350''f'$'\376\377\377\205\300''ur'$'\203\354\004''V'$'\377''t$'$'\030''j'$'\002\350\203\222'

The characters in the file name look like some character encoding. Do 
you know hat that is? UTF-8? The dumped output viewed in an editor shows 
a “Asian” looking characters 胒.

     $ last reboot
     reboot   system boot  5.9.0-4-686-pae  Fri Dec  4 21:10   still running
     reboot   system boot  5.9.0-4-686-pae  Sun Nov 29 17:56 - 17:02 
(4+23:05)
     reboot   system boot  5.9.0-1-686-pae  Sun Nov 29 09:37 - 12:50 
(03:12)
     reboot   system boot  5.9.0-1-686-pae  Sat Oct 31 20:49 - 23:40 
(02:50)

So, I ran

     Nov 29 10:58:55 mattotaupa sudo[2214]:     paul : TTY=pts/0 ; 
PWD=/home/paul ; USER=root ; COMMAND=/usr/bin/apt full-upgrade

and that also touched `/boot/grub/i386-pc`.

The GRUB packages and Linux package were updated according to 
`/var/log/dpkg.log.1`.

     2020-11-29 11:38:06 upgrade grub2-common:i386 2.04-9 2.04-10
     […]
     2020-11-29 12:04:00 status installed 
linux-image-5.9.0-4-686-pae:i386 5.9.11-1
     […]
     2020-11-29 12:13:24 configure grub-pc:i386 2.04-10 <none>
     2020-11-29 12:13:24 status unpacked grub-pc:i386 2.04-10
     2020-11-29 12:13:24 status half-configured grub-pc:i386 2.04-10
     [Dialog waited for my confirmation: Some GRUB warning regarding 
block devices, which I always “ignore”, that means tell GRUB to be upgraded]
     2020-11-29 12:43:21 status installed grub-pc:i386 2.04-10
     […]

So, afterward I was able to reboot without any issues.

But now, it gets really confusing. `last` claims, the system was running 
for four days. But that was not the (power was unplugged in between). I 
also can’t remember the shutdown failing in some strange way. In the 
systemd journal, it’s also recorded as one boot, but messages are 
missing, supporting it was powered off in between.

     Nov 29 17:57:00 mattotaupa kernel: Linux version 5.9.0-4-686-pae 
(debian-kernel@...ts.debian.org) (gcc-10 (Debian 10.2.0-19) 10.2.0, GNU 
ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.11-1 (2020-11-27)
     Nov 29 17:57:00 mattotaupa kernel: random: get_random_u32 called 
from bsp_init_amd+0x12f/0x220 with crng_init=0
     […]
     Nov 29 17:57:51 mattotaupa tracker-miner-f[1130]: Unable to get XDG 
user directory path for special directory &MUSIC. Ignoring this location.
     Nov 29 17:57:51 mattotaupa tracker-miner-f[1130]: Unable to get XDG 
user directory path for special directory &PICTURES. Ignoring this location.
     Nov 29 17:57:51 mattotaupa tracker-miner-f[1130]: Unable to get XDG 
user directory path for special directory &VIDEOS. Ignoring this location.
     Dez 04 14:48:12 mattotaupa systemd-timesyncd[706]: Initial 
synchronization to time server [2a01:4f8:120:9224::2]:123 
(2.debian.pool.ntp.org).
     Dez 04 14:48:12 mattotaupa systemd[1]: Starting exim4-base 
housekeeping...
     Dez 04 14:48:12 mattotaupa systemd[1]: Starting Daily man-db 
regeneration...

So, something really strange happened. But looking more into this, and 
that I wasn’t definitely not home on November 29th, 2020 at 17:57, I 
think the system time was just incorrect.

The (old) drive seems alright.

```
$ sudo smartctl -i /dev/sdb
smartctl 7.1 2019-12-30 r5022 [i686-linux-5.9.0-4-686-pae] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green (AF)
Device Model:     WDC WD20EARS-60MVWB0
Serial Number:    WD-WCAZA4234015
LU WWN Device Id: 5 0014ee 20585a39e
Firmware Version: 51.0AB51
User Capacity:    2.000.398.934.016 bytes [2,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Sat Dec  5 20:08:13 2020 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
$ sudo smartctl -H /dev/sdb
smartctl 7.1 2019-12-30 r5022 [i686-linux-5.9.0-4-686-pae] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
```

Please find `sudo smartctl --all /dev/sdb` attached.

Do you want me to re-install grub to see if it’s a problem introduced in 
Debian’s GRUB 2.04-10?

> grub2 (2.04-10) unstable; urgency=medium
> 
>   [ Ian Campbell ]
>   * Remove myself from uploaders.
> 
>   [ Colin Watson ]
>   * When upgrading grub-pc noninteractively, bail out if grub-install fails.
>     It's better to fail the upgrade than to produce a possibly-unbootable
>     system.
>   * Explicitly check whether the target device exists before running
>     grub-install, since grub-install copies modules to /boot/grub/ before
>     installing the core image, and the new modules might be incompatible
>     with the old core image (closes: #966575).
>   * Cherry-pick from upstream:
>     - tftp: Roll-over block counter to prevent data packets timeouts
>       (LP: #1892290).
> 
>   [ Dimitri John Ledkov ]
>   * grub-install: Add backup and restore.
>   * Don't call grub-install on fresh install of grub-pc.  It's the job of
>     installers to do that after a fresh install.
> 
>  -- Colin Watson <cjwatson@...ian.org>  Sun, 08 Nov 2020 16:26:08 +0000


Kind regards,

Paul

View attachment "dumpe2fs.txt" of type "text/plain" (20488 bytes)

View attachment "smartctl-all-dev-sdb.txt" of type "text/plain" (4877 bytes)

Powered by blists - more mailing lists