My guix installation appears to be working now. Thanks for all your help! I'm not sure if the underlying issue causing the encoding error has been identified; if there's anything else you need from me let me know. It appears that this error is not causing any bad behavior, however. On Wed, Jan 23, 2019 at 7:42 AM Bryan Ferris wrote: > I am indeed using flash storage, specifically a Samsung Evo 850 (it's a > few years old and has had many distress installed and reinstalled on it; > now that I'm thinking about it, it wouldn't surprise me at all if this was > the underlying issue). I'm trying your recommendation of reinstalling and > waiting now. I doubt the installation will finish before I leave for work, > so it will certainly sit for at least 5min. > > Is there any way that we can verify that the files have finished writing? > It seems difficult if the hardware is willing to straight-up lie to us... > > On Mon, Jan 21, 2019, 02:16 Danny Milosavljevic wrote: > >> Hi Ludo, >> Hi Bryan, >> >> On Mon, 21 Jan 2019 10:50:41 +0100 >> Ludovic Courtès wrote: >> >> > It’s not surprising to .lock files to be empty. >> >> I agree. But I didn't filter them out because it would be confusing. >> >> > But where are those >> > files you’re talking about? Surely there’s no /gnu/store on the VFAT >> > EFI partition, right? >> >> Oh, these empty files are on the root partition Bryan provided - there >> are lots and lots of empty files, including very important ones like the >> pam configuration files and the elogind configuration files (which is why >> the login didn't work). >> >> It looks like something crashed or sync(2) wasn't called before reboot or >> something. >> >> Some flash storage devices like to lie about whether they synced something >> (they'll say they did sync but they really didn't yet). If one then cuts >> the power it leads to data loss. But that's all speculation. >> >> @Bryan: Would you be up to doing the installation again but then before >> the >> reboot do a manual invocation of "sync" and then wait 5 min before >> rebooting? >> Is it flash storage? >> >> I didn't check the contents of the ESP partition because they don't >> matter. >> What matters is whether the ESP partition is dirty (it was) and whether a >> manual invocation of "fsck.vfat" succeeds on it (it does). >> >> Out of curiousity I checked ESP anyway now. It has: >> >> EFI >> EFI/GuixSD >> EFI/GuixSD/grubx64.efi >> >> $ ls -l EFI/GuixSD/grubx64.efi >> -rwxr-xr-x 1 root root 155136 11. Jan 16:52 >> /mnt/tmp/EFI/GuixSD/grubx64.efi >> >> That's all there is in the ESP partition. >> >