FreeBSD mounting of external drives for the Linux user
Just another quick note for Linux users switching to BSD: the mounting behavior is a little different. You might have beem OK in a modern Linux distribution oriented for the desktop by simply mounting the drive and watching it automagically in your file manager, much like Windows. Not so fast in FreeBSD.
Not only automounting is disabled by default, the very mount
command itself behaves differently: unlike in Linux where the filesystem type is guessed from the information available in the disk, FreeBSD will by default attempt to mount it as one of its own UFS type unless instructed otherwise with the flag -t
. The available filesystem types also are not very intuitive from a Linux background as the options are: cd9660, mfs, msdosfs, nfs, nullfs, smbfs, udf
, and unionfs
. I would not have guessed what was the name for FAT32 there before looking at mount(8)
.
Finally, device files also have a different naming convention. UFS in FreeBSD takes an additional step in Linux's division of disks in drives and partitions, and also adds the concept of slices on top. So a root partition on an install disk like /dev/sda1
in Linux may look like this in FreeBSD:
/dev/ada0p2
^^^|||-> disk
^^|-> partition
^-> slice
So how does a single partition USB drive like /dev/sdb
look like? In my case: /dev/da0
. And that's what you'd need to mount with the combined knowledge of the previous paragraphs.
So this is an example of a sequence of commands I'd use to mount a single-partition FAT32-formatted USB drive:
sudo dmesg | tail -20 # find the name of the connected drive in messages
sudo mkdir /media/extdrive # let's create a convenient mountpoint
# optional step, makes the mounted drive writable for your user:
sudo chown $USER:$USER /media/extdrive
sudo chmod 750 /media/extdrive
# actually mount your drive (watch for the actual name)
sudo mount -t msdosfs /dev/da0 /media/extdrive
# You can now browse and write to the drive via your file manager.
# unmount after done:
sudo umount /media/extdrive
And this is it! A little learning here and there and making yourself comfortable with as many OSes as possible goes a long way!
Sanest way I've found so far to transfer files from Android phone to Linux
Maybe it's just me, but for some mysterious reason, I find that transferring files out of my Android phone using a cable - or at least not without having to download an app, often proprietary, to "allow" me to do what should've been a no-brainer in first place. Maybe Google secretly doesn't want anyone having access to, you know, cheap massive storage like laptop drives so that they instead turn to cloud storage that they control?
Whatever the case, I've already tried standard file manager transfers, MTP mode switching, "transfer clients" and nothing seemed to work. And then I tried to wirelessly transfer them using my home wifi, using something like Ghost Commander. Also no goal: the phone keeps going to sleep and the OS blocks the process to "save battery" or something. This annoyance made me look for certain hacks such as showing a movie on endless repeat until the transfer was complete, but that was silly.
After so many frustrated trial and error attempts, I've finally settled on something that - even if not perfect - works for me. This is what I did to help myself:
- Install Primitive FTPd from F-Droid.
- Open the app and set up a username / password if you want. For the access method, select
Plain old filesystem
. Grab a hold of the IP address showing up in the screen and start the server. - In the computer, connect to your phone via FTP with:
ftp server_address 12345
and authenticate with your credentials you just set. -
Issue the following two commands to allow transferring of any file in bulk (no interaction):
ftp> binary ftp> prompt
-
Locate the files you want to transfer. For example, the photos I took:
ftp> cd DCIM/Camera
-
Transfer them with
mget FILE1 FILE2 ...
or glob it likemget *
.
The transfer will go on, and Primitive does not allow the phone to sleep while it runs in the foreground, which means you don't have to worry about keeping it awake.
And that's it. It's not in any way a perfect solution, and does require installing an app, but it's waaaaay less hassle than others and everything in this stack is Free Software (ok, minus Android). And that's what I've been doing to back up my pictures.
Do you know of any better way, something simpler or faster? More secure, perhaps? Let me know!
Road to getting a persistent install of Puppy Linux in a USB
The original mission was simple enough: get a Puppy Linux installation in a USB drive so I can have a portable Linux environment. Oh, easy does it. I can simply dd
the image file into any one that I have lying around and that will be it! But here's the compication: it has to persist some things in order to make itself useful should I ever re-use it again.
But wait a second! If you use dd
the drive essentially becomes read-only and worse: any additional space not accounted by the ISO disk image is wasted! For drives 4GB and larger, this is a significant loss. So I'll have to extract the contents in another way.
Oh, I know: Unetbootin! It's the easy-peasy solution to write stuff and keep them with a writable FAT32 filesystem. I've used since I was with Ubuntu back in the days, and should work with such a mobile distro such as Puppy, right?
Ehi, wrong... who knows, maybe it's outdated? Or Puppy outgrew its extraction system? Okay, that leaves us with the new cool kid on the block: Ventoy. Could this shiny new program be the answer to it all? It certainly looks so: Ventoy prepares new drives in a way that you can easily add, remove and swap distros, truly an elegant and modern answer for an age-old problem of multiboot on any media.
Unfortunately, persistence is provided with a separate plugin which I don't have time to read about at the moment. So now I'm running out of options, what is left for me? Here's where sometimes the simplest answers are the best.
Turns out that Puppy has a "Puppy installer" option right in their graphical setup wizards which allows us to install a copy of the ongoing live session direct to the plugged in USB drive - complete with writable persistence files and session saving capabilities! All you have to do is, from an ongoing Puppy session, plug in your USB and run the install wizard. The only downside is that it requires two drives to produce an optimal drive. But whatever; it worked.
And now this is the drive I'm using to try out Vanilla Dpup, the Debian-core flavor of Puppy Linux. Let's see if this becomes another review in the future!
Welcome to my part of Town!
I'm Klaus Zimmermann, the friendly hacker formerly very active on Quitter.se and GNUSocial in general. Although my social time has been diminishing quite a lot recently, I've discovered a new home (and an entire new world!) here in Tilde Town.
I'll share some of my thoughts, Linux and Infosec tutorials and other stuff here. Be sure to check back! I develop some scripts for fun and write python as a hobby, which I plan to share here as well. You can also look under /home/kzimmermann/
via ssh for more information.
Also, see my Random collection of thoughts. It's like a microblog, a twitter feed or something minus the tracking and bloat!
Elsewhere on the web
I used to have a Quitter.se account where I was quite active until about 2018 when it went under. I had alternative accounts named kzimmermann2
but kind of gave up when quitter went under.
I currently have a presence in the hacker social media spirit through my account in Mastodon (changed on October 8th 2020), though I'm still a little slow to get posting there again. Who knows, I might get back to it now that Tilde Town revived that spirit in me!
I hold a figurative account at Github, though my real software projects remain in the community-oriented Notabug.org. I feel I should mirror them back into Github for safety some time.
Contact
To reach out to me, hit me up in my Fediverse account. Public mentions or DMs are fine.
Alternatively, get in touch via instant messaging via XMPP at this address: kzimmermann _At@Sign_ kchat.port0.org
(use your logic to deduce how to build it). I would prefer PGP encryption for this, unless you're fine with accumulating lots of OMEMO keys.
See this post for more information.