From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bryan Ferris Subject: bug#33999: CP437: Invalid Argument on init Date: Sat, 26 Jan 2019 09:32:49 -0800 Message-ID: References: <20190109200804.5619d668@scratchpost.org> <87tvi8vpds.fsf@gnu.org> <20190118235945.19009d9e@scratchpost.org> <20190121014031.3f2f37a6@scratchpost.org> <878szel4pa.fsf@gnu.org> <20190121111641.49665997@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000cfceb305805fd566" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:47892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gnRqF-0000Kp-BV for bug-guix@gnu.org; Sat, 26 Jan 2019 12:34:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gnRqE-0000rx-7G for bug-guix@gnu.org; Sat, 26 Jan 2019 12:34:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:47487) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gnRqE-0000rs-48 for bug-guix@gnu.org; Sat, 26 Jan 2019 12:34:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gnRqD-0004h8-Um for bug-guix@gnu.org; Sat, 26 Jan 2019 12:34:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Danny Milosavljevic Cc: 33999@debbugs.gnu.org --000000000000cfceb305805fd566 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wa= s > 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=C3=A8s wrote: >> >> > It=E2=80=99s 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=E2=80=99re talking about? Surely there=E2=80=99s no /gnu/st= ore 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 wh= y >> the login didn't work). >> >> It looks like something crashed or sync(2) wasn't called before reboot o= r >> something. >> >> Some flash storage devices like to lie about whether they synced somethi= ng >> (they'll say they did sync but they really didn't yet). If one then cut= s >> 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. >> > --000000000000cfceb305805fd566 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 el= se 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 Ferri= s <saffsnail@gmail.com> wr= ote:
I am indeed using flash storage, specifically a Samsung Evo 850 (it&= #39;s a few years old and has had many distress installed and reinstalled o= n it; now that I'm thinking about it, it wouldn't surprise me at al= l 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 <dannym@scratchpost.org wrote:
Hi Ludo= ,
Hi Bryan,

On Mon, 21 Jan 2019 10:50:41 +0100
Ludovic Court=C3=A8s <ludo@gnu.org> wrote:

> It=E2=80=99s not surprising to .lock files to be empty.

I agree.=C2=A0 But I didn't filter them out because it would be confusi= ng.

> But where are those
> files you=E2=80=99re talking about?=C2=A0 Surely there=E2=80=99s no /g= nu/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<= br> (they'll say they did sync but they really didn't yet).=C2=A0 If on= e then cuts
the power it leads to data loss.=C2=A0 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 befor= e 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.=C2=A0 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.
--000000000000cfceb305805fd566--