For what it’s worth, I use minicom exclusively and have not had it crash. This is on Ubuntu 22.04.4, minicom v2.8.
1 Like
I’m migrating and chose 24.04 LTS. It aligned with Mint on the kids laptops. I have had some of the issues being duscussed, just no time to document. To be continued.
1 Like
Ah. I’m in the middle of too much to upgrade right now.
If I have time I can spin up a 24.04 VM and give it a try.
I had some time to set up a new Ubuntu 22.04 VM and install minicom to do some testing. I was not able to get minicom to crash.
Here’s what I did:
- Set up brand new Ubuntu 22.04 VM using Linux QEMU/KVM host:
Ubuntu 24.04.1 LTS x86_64 - Did an
apt update && apt upgradeto make sure it’s up to date - Flashed bus pirate with the version from this post: Bus Pirate 5 resetting itself, causing storage corruption - #23 by BusPirateV5
Install Minicom
bptest24@bpTest:~$ minicom --version
minicom version 2.9
Copyright (C) Miquel van Smoorenburg.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version
2 of the License, or (at your option) any laterversion.
I did some more playing with different functions and had no issues. Were you doing anything in particular with it, or did it crash right away?
1 Like
Im going to find time tomorrow to walk thfoigh this and a few related issues. Thank you for all of the info! Ill post mu findings here.
There’s a new storage problem with the current version. On Linux if you do the following steps:
- plug in BP5
- cp file.txt /media/$USER/BUS_PIRATE5/file.txt
- umount /media/$USER/BUS_PIRATE5/file.txt
- Unplug and replug BP5
At this point - the file “file.txt” is not found on the BP.
If I just unplug the BP, the file system is “in use” and marked dirty, and it won’t remount the file system.
I’ve seem similar problems by typing the “#” command in the terminal window.
When I run the file system check, it says the file system is marked dirty, and won’t remount the file system. I have to run “fsck” and fix the drive.
I am seeing nearly the same on Ubuntu Linux 24.04.4. I hadn’t noticed before because I usually don’t copy from host → BP; I’m usually going from BP to host.
The difference is that the Ubuntu host will always remount the filesystem. Kernel log shows it’s dirty, but will still mount it. The last file may or may not show up on the volume - it may depend on how long I waited before unmounting, but I haven’t found a solid pattern.
I see this in the kernel log:
[ 8439.681463] sd 1:0:0:0: Attached scsi generic sg1 type 0
[ 8439.690669] sd 1:0:0:0: [sdb] 47824 2048-byte logical blocks: (97.9 MB/93.4 MiB)
[ 8439.691465] sd 1:0:0:0: [sdb] Write Protect is off
[ 8439.691472] sd 1:0:0:0: [sdb] Mode Sense: 03 00 00 00
[ 8439.692266] sd 1:0:0:0: [sdb] No Caching mode page found
[ 8439.692269] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[ 8439.712926] sdb: sdb1
[ 8439.713224] sd 1:0:0:0: [sdb] Attached SCSI removable disk
[ 8443.139949] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
I’m also trying to find the exact pattern. It’s a little frustrating. I can’t edit a file on the BP, and I am trying to write a simple script.
Does this seem like a regression, or a newly discovered issue?
A regression. I recall you made a change (for Windows-specific issues? I can’t find the post). Before that - things seem solid. My Linux script I shared makes things very easy. It either connects (if the BP file system is mounted), or it updates (if the RPi file system is mounted). I never had to leave the terminal window or use the mouse.
But this recent version is a real pain to use.
The only change to the MSD going back to mid-early October appears to be this update to the descriptors.
I may not have noticed this behavior before; as I said, I normally don’t move files in that direction.
I can try git bisecting it later this morning.
Odd. I noticed it first (with the newest version) when I typed “#” and the file system didn’t remount RW. Instead, it didn’t mount at all, even after unplugging and replugging the BP.
I can try to find an old version searching for zip files on this site. (I’m not a git guru, and I don’t know how to bisect,)
I may be speaking to soon, and sorry. This might not be a regression. Copying a file and then unmounting the file system is something new I am doing. The other problem I mentioned I can’t repeat reliably. So let’s treat this as a new bug for now, Ian. Sorry, Ian.
2 Likes
I’ll hold off on bisecting, then.
I agree that it’s a different process to manually unmount. Looking back at my notes, when testing this I would write a file from host to BP, then open serial I/O with minicom. The BP handles the requests for flushing and remounting.
Maybe do a sync from the command line before unmounting?
1 Like
You could just script it like:
#! /bin/sh
sync
sync
sleep 1
sudo umount /dev/sdb1
Or wherever the filesystem mounts on your box.
It’s definitely not a regression. I just tried the same steps on old firmware 2024-09-03T13:22:59Z and this still occurs. So it is a new problem that no one has tried before…
3 Likes
I updated, BTW. To add to the bug report, I just copied a file onto the BP, then verified the file was there using the Unix command “more”, connected to the BP, and the file was not updated.
I finally got the file copied onto the BP. I connected to the BP, and the file was there. I used the BP “cat” command to look at the file. It was the new version. I then tried to run the file as a script.
It failed. Then I used the BP “cat” command again to look at the file, and it was the old version.
This is very similar to the very first firmware with no guarding between the OS and MCU access to the file system. It is on my short-ish term list to add a mode where the storage is only visible to one of the other. That may be the only way to solve it in some instances.
I can get the file onto the BP, but I am not sure of the exact sequence to make it repeatable. Essentially I keep trying, and it works.