From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F91DC4167B for ; Sun, 6 Dec 2020 15:16:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6CA1E23332 for ; Sun, 6 Dec 2020 15:16:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726685AbgLFPQd (ORCPT ); Sun, 6 Dec 2020 10:16:33 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:44296 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726198AbgLFPQd (ORCPT ); Sun, 6 Dec 2020 10:16:33 -0500 Received: from callcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0B6FFRN8007311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Dec 2020 10:15:28 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 937F0420136; Sun, 6 Dec 2020 10:15:27 -0500 (EST) Date: Sun, 6 Dec 2020 10:15:27 -0500 From: "Theodore Y. Ts'o" To: Colin Watson Cc: Paul Menzel , Andreas Dilger , linux-ext4@vger.kernel.org, Dimitri John Ledkov Subject: Re: ext4: Funny characters appended to file names Message-ID: <20201206151527.GE577125@mit.edu> References: <20201204152802.GQ441757@mit.edu> <93fab357-5ed2-403d-3371-6580aedecaf4@molgen.mpg.de> <20201204180541.GC577125@mit.edu> <51a1939c-2a99-e86a-1799-c31248e21d89@molgen.mpg.de> <20201206144416.GM13361@riva.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201206144416.GM13361@riva.ucam.org> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sun, Dec 06, 2020 at 02:44:16PM +0000, Colin Watson 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 I think Colin theory makes sense. Note the hypthen after "boot.img". That corresponds with the 'i' in the code below: > Now that I look at it more closely, some of the changes to > clean_grub_dir_real look suspicious: > > + char *srcf = grub_util_path_concat (2, di, de->d_name); > + > + if (mode == CREATE_BACKUP) > + { > + char *dstf = grub_util_path_concat_ext (2, di, de->d_name, "-"); > + if (grub_util_rename (srcf, dstf) < 0) > + grub_util_error (_("cannot backup `%s': %s"), srcf, > + grub_util_fd_strerror ()); > + free (dstf); > + } ... however, if I'm understanding the code correctly, this is the codepath used to create the backup file (e.g., the previous version of boot.img). So shouldn't there be a "boot.img" file in /boot/grub/i386-pc which would be the newly installed version of that file, and so the system would actually be booting correctly? Or am I misunderstanding what is going on? Paul, I thought you said your system wasn't able to boot because the needed files in /boot/grub/i386-pc had apparently been corrupted? Essentially, there are three possibilities: 1) A hardware corruption which corrupted the directory. 2) A kernel bug which corrupted the directory. 3) The file system isn't actually corrupted, but the filename with the random garbage in the filename was created because a userspace application so requested it. The fact that all of the filenames have the a similar pattern of corruption to them would tend to rule out #1. And the fact that e2fsck didn't notice any other corruptions would tend to argue against #1 and #2. So #3 does seem to be the most likely. - Ted