You are not logged in.

#1 2019-10-15 20:18:18

Nazinho
Member
Registered: 2019-10-15
Posts: 2

[SOLVED] Installing boot loader cause filesystem corruption on USB key

I'm facing a very weird problem to install Arch on a USB key.

I followed the official wiki guide to get a persistent Arch installation on a USB key. Everything goes fine with the installation until I try to install a boot loader. After pacstrap finishes with a very small set of packages (base base-devel linux grub efibootmgr nano), I am able to chroot to the mounted system and continue the system configuration and run any command. The problem is that trying to install a boot-loader seems to leave the filesystem corrupted: I get a lot of messages from dmesg of ext4 corruption and if I dismount the partition, mount again, the system is completely gone and e2fsck is not able to recover it.
I'm doing the install from Arch Live booted as EFI.

The device is a SanDisk® Firebird® 32GiB.

The drive is OK, I'm able to use it as a regular USB key.

The GPT partition table layout is as below:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdc      8:32   1 31.3G  0 disk
├─sdc1   8:33   1    1G  0 part
└─sdc2   8:34   1 30.3G  0 part

where
| sdc1: EFI partition formatted with

mkfs.fat -F32

| sdc2: ext4 filesystem for Arch formatted with

mkfs.ext4 -O "^has_journal"

The partitions are mounted with

mount /dev/sdc2 /mnt
mount /dev/sdc1 /mnt/boot

I've tried two different boot-loaders, both caused the same problem.

The exact commands used to install the boot-loader were these:

• GRUB:

grub-install --target=x86_64-efi --efi-directory=/boot  --removable --recheck

• systemd-boot:

bootctl --path=/boot install

N.B.: I've also tried f2fs but, apart from silent dmesg, the FS suffers from the same malaise

N.B.: MBR+BIOS with GRUB didn't worked either.

I tried different approaches which required me to reinstall Arch almost 15 times, all produced the same result.

What am I doing wrong?

Last edited by Nazinho (2019-10-18 12:31:18)

Offline

#2 2019-10-18 10:41:24

WSDMatty
Member
Registered: 2019-08-27
Posts: 20

Re: [SOLVED] Installing boot loader cause filesystem corruption on USB key

I have my /boot directory for this laptop on a separate drive. I used GRUB with a BIOS BOOT partition. This is the setup.

sdb             8:16   1  14.6G  0 disk  
├─sdb1          8:17   1     1M  0 part  (bios boot)
├─sdb2          8:18   1   512M  0 part  (/boot)
└─sdb3          8:19   1  14.1G  0 part (misc data)

This setup works flawlessly for me. You could give this setup a go.

As for what you're doing wrong, I don't know anything about EFI systems.
But I can see that in the GRUB install line, you're missing

--bootloader-id=GRUB

and that could make a difference?

Offline

#3 2019-10-18 12:28:14

Nazinho
Member
Registered: 2019-10-15
Posts: 2

Re: [SOLVED] Installing boot loader cause filesystem corruption on USB key

Weird enough this seems like the problem is on the USB key. Tried to install again this time on my old 16GiB FireBlade ® and everything is set ok. After investigating further I discovered that the device is unable to keep a partition table properly (making a new one with gdisk removing the key and reinserting is enough to cause a GPT corruption) even though it would let me carry data around. I may be a victim of counterfeiting, which is unfortunately somewhat common where a live *sigh*.

Apart from that, your setup seems very similar to mines (except for the 1M gap needed to install BIOS).

I am marking this as [SOLVED] as the problem is not related to Arch.

Last edited by Nazinho (2019-10-20 17:23:30)

Offline

#4 2019-12-30 19:16:47

cmurf
Member
Registered: 2019-09-06
Posts: 26

Re: [SOLVED] Installing boot loader cause filesystem corruption on USB key

Highly recommend using f3 to test all USB sticks. I don't see it packaged but you can find it here.
http://oss.digirati.com.br/f3/

The gist is, you format the USB stick (any format will do and it doesn't need to be partitioned, so e.g. you could use UDF or FAT32), mount it, and then `f3write /mountpoint` and wait until that's done. Then do `f3read /mountpoint` and wait until that's done. It tests for corruption, but also fake flash where the drive reports it's a bigger size than it really is, with firmware that loops over the same backing flash chip multiple times to fake the bigger size. If you don't use much of the flash stick, it'll appear to work, but at a certain point once it loops, it starts to overwrite previously written data, corrupting it. And that has a specific pattern. So yeah, f3 for the win.

You could also get a bit nutty and do an f3write, put the stick on a shelf for X amount of time, then do f3read. That tests for a kind of time based bit rot. But your best bet is to not buy flash sticks online, buy locally from a reputable vendor+distributor or even go direct to the company. There's a glut of fake flash.

Offline

Board footer

Powered by FluxBB