Dev1 Galaxy Forum / Raspberry Pi 3B+ and botting from USB port

Re: Raspberry Pi 3B+ and botting from USB port

dummy@example.com (Altoid) — Sat, 06 Jun 2020 21:46:56 +0000

Hello:

Camtaf wrote:

... Devuan image doesn't have the USB drivers built in ....

Altoid wrote:

Does this have a way around it?

No one?

Thanks in advance,

Re: Raspberry Pi 3B+ and botting from USB port

dummy@example.com (Altoid) — Thu, 28 May 2020 20:49:55 +0000

Hello:

Camtaf wrote:

... Devuan image doesn't have the USB drivers built in ....

You were exactly right ... =-)
Size or FAT16/32 does not matter.

I can start to boot with a 128Mb or 256Mb partition, either FAT16 or FAT32.

But it always stops here:
eg: 128Mb FAT16

--- snip ---
[    ] sd 0:0:0:0  [sda] 3970048 512-byte logical blocks: (2.03GB/1.89GB) 
[    ] sd 0:0:0:0  [sda] Write Protect is off
[    ] sd 0:0:0:0  [sda] No Caching mode page found
[    ] sd 0:0:0:0  [sda] Assuming drive cache: write through
[    ] sda: sda1 sda2
[    ] sd 0:0:0:0  [sda] Attached SCSI removable disk
_

Does this have a way around it?

Thanks in advance,

Re: Raspberry Pi 3B+ and botting from USB port

dummy@example.com (Altoid) — Thu, 28 May 2020 13:30:34 +0000

Hello:

Camtaf wrote:

... Devuan image doesn't have the USB drivers built in ...

I'm not too clear on how the boot process in ARM64 works.
I've always been on x86/x86_64 ie: w/BIOS booting

But like you, I don't think it is a size issue but cannot rule it out.

Found this:

OP wrote:

I have upgraded three RPS 3B+ now and can tell, in all cases there were crashes during the installation process. Then I resized the boot partition to 240 GB and had no more problems.
Resizing the FAT partition with GParted is tricky: you must
1. backup the files in /boot
2. reformat the partition as ext4
3. resize and move both partitions
4. reformat the first partition to FAT32
5. relabel the partition to boot
6. restore the files from the backup
Sounds scary, but this worked for me.

Here it is most probably a question of the size of the partition vs. the size of the update.
One would think that in a properly packaged upgrade, instead of a crash, some script would check that the update would actually fit the partition.

But I digress.

Thinking that the problem is probably in the type of partition and not the size, I had a look at their main characteristics.
I burned different images for Raspberry Pi 3B + on an SDcard and did blkid, parted -l and fdisk-l on each to compare the results:

1. devuan_ascii_2.0.0_arm64_raspi3.img

blkid

/dev/sdf1: SEC_TYPE="msdos" UUID="EEA4-304A" TYPE="vfat" PARTUUID="ac806f8a-01"
/dev/sdf2: UUID="589c7999-62be-47ac-8847-32b62fd9fdc9" TYPE="ext4" PARTUUID="ac806f8a-02"

parted -l

Model: Generic Mass-Storage (scsi)
Disk /dev/sdf: 2033MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  135MB   134MB   primary  fat16        boot, lba
 2      135MB   1983MB  1848MB  primary  ext4

fdisk -l

Disk /dev/sdf: 1.9 GiB, 2032664576 bytes, 3970048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xac806f8a

Device     Boot  Start     End Sectors  Size Id Type
/dev/sdf1  *      2048  264191  262144  128M  c W95 FAT32 (LBA)
/dev/sdf2       264192 3872767 3608576  1.7G 83 Linux

2. 2020-02-13-raspbian-buster-lite.img

blkid

/dev/sdf1: LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" PARTUUID="738a4d67-01"
/dev/sdf2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" TYPE="ext4" PARTUUID="738a4d67-02"

parted -l

Model: Generic Mass-Storage (scsi)
Disk /dev/sdf: 2033MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      4194kB  273MB   268MB   primary  fat32        lba
 2      273MB   1850MB  1577MB  primary  ext4

fdisk -l

Disk /dev/sdf: 1.9 GiB, 2032664576 bytes, 3970048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x738a4d67

Device     Boot  Start     End Sectors  Size Id Type
/dev/sdf1         8192  532479  524288  256M  c W95 FAT32 (LBA)
/dev/sdf2       532480 3612671 3080192  1.5G 83 Linux

3. LibreELEC-RPi2.arm-9.2.1.img

blkid

/dev/sdf1: LABEL="BOOT" UUID="22BD-E464" TYPE="vfat" PARTUUID="08de5300-01"
/dev/sdf2: LABEL="RECALBOX" UUID="9c7b2218-a4be-431c-900c-733cb0382b28" TYPE="ext4" PARTUUID="08de5300-02"
/dev/sdf3: LABEL="SHARE" UUID="e5113429-80b8-4347-bd0d-802da4c4726e" TYPE="ext4" PARTUUID="08de5300-03"

parted -l

Model: Generic Mass-Storage (scsi)
Disk /dev/sdf: 31.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      512B    67.1MB  67.1MB  primary  fat32        lba
 2      67.1MB  2215MB  2147MB  primary  ext4
 3      2215MB  31.9GB  29.7GB  primary  ext4

fdisk -l

Disk /dev/sdf: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x08de5300

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdf1             1   131072   131072   64M  c W95 FAT32 (LBA)
/dev/sdf2        131073  4325376  4194304    2G 83 Linux
/dev/sdf3       4325377 62333951 58008575 27.7G 83 Linux

It was parted -l that showed me what the real difference was:

1. Devuan ascii 2.0.0

Disk Flags:
Number  Start   End     Size    Type     File system  Flags
 1      1049kB  135MB   134MB   primary  fat16        boot, lba

2. Raspbian Buster-lite

Disk Flags:
Number  Start   End     Size    Type     File system  Flags
 1      4194kB  273MB   268MB   primary  fat32        lba

3. LibreElec 9.2.1

Disk Flags:
Number  Start   End     Size    Type     File system  Flags
 1      512B    67.1MB  67.1MB  primary  fat32        lba

In Devuan ascii the first partition is primary fat16 boot, lba.
But while in the other two Raspbian/Debian based images the first partition is also primary and lba, it is fat32 and does not have the boot flag set.

Any one with more experience in these matters care to pitch in?

The RPi 3b+ with the OTP bit set (now by default) allows more flexibility in that instead of booting only from the SDCard slot, it will first try to boot from an SDCard and if there's no boot system there, from a USB slot.

It would be great if the Devuan ARM64 images could take advantage of this feature.

Thanks in advance,

Re: Raspberry Pi 3B+ and botting from USB port

dummy@example.com (Camtaf) — Thu, 28 May 2020 08:11:47 +0000

Maybe the Devuan image doesn't have the USB drivers built in - I've come across this with other distros, (& BSD).

P.S. The larger first partition is for the RPi4, (but doesn't harm other Rpi).

Raspberry Pi 3B+ and botting from USB port

dummy@example.com (Altoid) — Wed, 27 May 2020 00:05:52 +0000

Hello:

The Raspberry Pi 3B+ supports mass storage boot, unlike other models ( 2B v1.2, 3A+, 3B) which needed a one-time programming of the OTP bit via a line at the end of /boot/config.txt.
I have checked my RPi and verified that the bit is set:

root@rpidevuan:/home/pi# vcgencmd otp_dump | grep 17:
17:3020000a
root@rpidevuan:/home/pi#

I have also been able to boot a Raspian image from a USB port using an SDCard reader and a standard size 2.0Gb card.
But if I want to boot the same SDCard with a Devuan image, it will not boot.

To compare how the images were burned to the cards, I did blkid and fdisk -l on each of the images after mounting:

Image: LibreELEC-RPi2.arm-9.2.1.img

# fdisk -l
--- snip ---
Disk /dev/sdf: 1.9 GiB, 2032664576 bytes, 3970048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x11072f7d

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdf1  *       8192 1056767 1048576  512M  c W95 FAT32 (LBA)
/dev/sdf2       1056768 1122303   65536   32M 83 Linux
--- snip ---

# blkid

--- snip ---
/dev/sdf1: SEC_TYPE="msdos" UUID="EEA4-304A" TYPE="vfat"
/dev/sdf2: UUID="589c7999-62be-47ac-8847-32b62fd9fdc9" TYPE="ext4"
--- snip ---

Image: devuan_ascii_2.0.0_arm64_raspi3.img

fdisk -l
--- snip ---
Disk /dev/sdf: 1.9 GiB, 2032664576 bytes, 3970048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xac806f8a

Device     Boot  Start     End Sectors  Size Id Type
/dev/sdf1         2048  264191  262144  128M  c W95 FAT32 (LBA)
/dev/sdf2       264192 3872767 3608576  1.7G 83 Linux
--- snip ---

blkid

--- snip ---
/dev/sdf1: SEC_TYPE="msdos" UUID="EEA4-304A" TYPE="vfat" PARTUUID="ac806f8a-01"
/dev/sdf2: UUID="589c7999-62be-47ac-8847-32b62fd9fdc9" TYPE="ext4"
--- snip ---

Besides the difference in size (512M vs 128M) the Raspbian image has the first partition with the boot flag set.

LibreELEC-RPi2.arm-9.2.1
---
/dev/sdf1 * 8192 1056767 1048576 512M c W95 FAT32 (LBA)
---

devuan_ascii_2.0.0_arm64_raspi3
---
/dev/sdf1 2048 264191 262144 128M c W95 FAT32 (LBA)
---

Now, if I set the boot flag on the SDCard with the devuan_ascii_2.0.0_arm64_raspi3 image, it still won't boot from the RPis USB port.

What am I missing?

Thanks in advance.