From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Colin Watson <cjwatson@debian.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
Andreas Dilger <adilger.kernel@dilger.ca>,
linux-ext4@vger.kernel.org, Dimitri John Ledkov <xnox@ubuntu.com>
Subject: Re: ext4: Funny characters appended to file names
Date: Sun, 6 Dec 2020 10:15:27 -0500 [thread overview]
Message-ID: <20201206151527.GE577125@mit.edu> (raw)
In-Reply-To: <20201206144416.GM13361@riva.ucam.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
next prev parent reply other threads:[~2020-12-06 15:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 14:30 ext4: Funny characters appended to file names Paul Menzel
2020-12-04 15:28 ` Theodore Y. Ts'o
2020-12-04 15:39 ` Paul Menzel
2020-12-04 18:05 ` Theodore Y. Ts'o
2020-12-05 19:34 ` Paul Menzel
2020-12-06 14:44 ` Colin Watson
2020-12-06 15:15 ` Theodore Y. Ts'o [this message]
2020-12-06 17:37 ` Colin Watson
2020-12-06 17:44 ` Colin Watson
2020-12-06 18:27 ` Colin Watson
2020-12-07 2:00 ` Dimitri John Ledkov
2020-12-04 20:02 ` Andreas Dilger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201206151527.GE577125@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=cjwatson@debian.org \
--cc=linux-ext4@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
--cc=xnox@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox