Error creating partition on USB disk

I plugged in a USB drive into my Raspberry Pi 4, deleted all the data using NethServer and then tried to create a partition but got the error below

From Clipboard

Note that using the command line I added a partition using fdisk using all of the defaults, which created a partition that I could format in cockpit. However, I do seem to have a small extra partition.

NethServer Version: 7.9
Module: Storage

just tried it on a smal (8GB) usb stick and it worked well:

first deleted all the partitions and then created a new one use the hole disk:

What kind of drive are you using?
Can you confirm the drive is fairly responsive?

The latter I’m asking because for the (cheap) Ewent 2,5"-sata to USB3 enclosure I had to fiddle around with usb-quirks at the kernel command line…

see:
https://www.raspberrypi.org/forums/viewtopic.php?t=245931

1 Like

I don’t think that’s the problem. Copying a large (GB size) file over the network to the drive goes about 7.0 MB/s according to scp (which opens another question - why does the raspberry pi 4 only connect at 100 Mbps as I believe its capable of 1 Gbps).

If I use cp to duplicate the file I get read and write speeds of ~100 MiB/s

The drive is a Portable SSD 240GB 550Mb/s Lexar SL100 External Solid State Drive USB-C.

Looking at the logs, I did see Requested start of the logical partition overlaps with extended partition metadata. Start of the partition moved to 1.

Andrew

scp tends to be slow: It runs over ssh which includes encryption. Do not think network speed is to blame for that.

This sounds good, so no usb-quirk problems

Seems like there was still some artifacts of the existing partitioning left over.

It says the link is only 100 Mbps. I have another raspberry pi 4 running Ubuntu MATE and it does connect at 1 Gbps

can you clarify where it say’s 100Mbps?

over here on 4GB model:
image

# ip a | grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 10.0.0.5/24 brd 10.0.0.255 scope global eth0

Note the 1000 on the end, IIRC that’s the speed the system reports. which ofcause does not imply it is actually reached…

External USB 3.0 connected SSD works well for me at the predicted speeds. I took a new drive and physically plugged it into the rp4, created the default partion table and format with a mount point on boot of /demossd.

Using the File Server module with SAMBA/AD as my account provider I was able to create a 2 file shares; one on the internal SD card storage and another that was symbolically linked to the SSD. Overall my RP4 share did well with large files with average speeds ~90 MB/s write but it did struggle when it came to many small files on the SSD. I do have random errors pop up however and wouldn’t consider this usable in it’s current form.

EDIT - external nfs mounts and shares also work but I have mixed speed/results.



That’s odd

[root@nethserver ~]# dmesg | grep eth0
[164771.671468] bcmgenet fd580000.ethernet eth0: Link is Down
[164771.671731] br0: port 1(eth0) entered disabled state
[164786.231744] bcmgenet fd580000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[164786.231901] br0: port 1(eth0) entered blocking state
[164786.231945] br0: port 1(eth0) entered forwarding state
[167714.916040] bcmgenet fd580000.ethernet eth0: Link is Down
[167714.916262] br0: port 1(eth0) entered disabled state
[167729.476315] bcmgenet fd580000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[167729.476472] br0: port 1(eth0) entered blocking state
[167729.476516] br0: port 1(eth0) entered forwarding state

That says 100 MBps

but

ip a | grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000

Says 1000 at the end like yours

The lights on my switch say its 100 Mbps

Yes it is, 1Gbps/Full … :

# dmesg | grep eth0
[    8.144345] bcmgenet fd580000.ethernet eth0: Link is Down
[   13.355083] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   13.362062] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 5247.375899] bcmgenet fd580000.ethernet eth0: Link is Down
[ 5251.417186] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 5251.417238] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 5251.420603] br0: port 1(eth0) entered blocking state
[ 5251.420652] br0: port 1(eth0) entered disabled state
[ 5251.420846] device eth0 entered promiscuous mode

Beats me: :thinking:

  • driver issue?
  • cable issue?
  • faulty RPI? (first time I would hear/read this…)
  • other reason?
1 Like

@mark_nl

It wouldn’t be the first time a switch has a defektive port. Try testing another Port on the switch.
It could be that the Switch has problems recognizing the RPI running with 1 GBit/s - and allocates only 100 MBit/S…

My 2 cents
Andy

2 Likes

It’s not the cable or switch - I swapped the cable that connects at 1 Gbps on my other Pi 4 and rebooted. It still only connected at 100 Mbps. Any other ideas on how I can diagnose?

Ta

Andrew

@arohl

Hi

The fastest check would be to pop in a SD with a standard Raspberry-OS in the questionable RPI and see if you get 100 or Gigabit…

If you get 100 MBit/s it’s hardware somewhere, not NethServer on RPI…

If you get Gigabit, that would implicate that NethServer is having problems with certain RPI hardware (It works for some without issues…).

My 2 cents
Andy

1 Like

One longshot probability :

The NIC on a RPI 4 behaves a bit strange: it reports to be ready but is not.

CentoOS brings up the network with networkmanger which has a NetworkManager-wait-online.service; Nethserver uses IFUP/IFDOWN which does not have such a service…

Also see closed issue at arm-dev

On the 7.8.2003 nethserver-image it is mitigated by waiting to start the nethwork.service until the kernel/systemd created/initialized the NIC:

mkdir /etc/systemd/system/network.service.d/
cat > /etc/systemd/system/network.service.d/wait-for-eth0.conf << EOF
[Unit]
After=sys-subsystem-net-devices-eth0.device
Requires=sys-subsystem-net-devices-eth0.device
EOF

As said a long shot, can not imagine this is the issue at hand…

@royceb what is your output of dmesg | grep eth0

1 Like
[root@ns1 ~]# dmesg | grep eth0
[    9.218936] bcmgenet fd580000.ethernet eth0: Link is Down
[    9.226852] br0: port 1(eth0) entered blocking state
[    9.226893] br0: port 1(eth0) entered disabled state
[    9.227231] device eth0 entered promiscuous mode
[   14.395400] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   14.395487] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   14.395702] br0: port 1(eth0) entered blocking state
[   14.395734] br0: port 1(eth0) entered forwarding state
1 Like

What does ethtool reports?

ethtool eth0

Is the switch managed and have custom speed settings for that port? Which switch brand and model?

1 Like

Maybe it’s a fake usb stick with wrong data about its size

Sorry for taking so long to replay. I believe the pi is faulty (if I simply put the boot SDCard into a different pi4 it worked fine) and have sent it back. Hopefully they will confirm the problem and send me a new one!

2 Likes