0

I've been experimenting with the g_mass_storage kernel module. I first tried loading it by putting it in /etc/modules and the options in /etc/modprobe.d/file.conf

This worked, but when I connected the device to a computer the mass file storage was read only - not what I was looking for.

I reasoned that this was because when the module loads, the root filesystem is mounted as read-only - not read-write.

This is an issue, because the kernel driver tries to get a read-write file handle for its backing storage, and if it can't negotiate this rw handle, it falls back to read-only.

The only solution I can think of is moving the loading of the kernel module later in the boot sequence.

I moved the module initialisation to /etc/rc.local using modprobe, and this worked with both reading & writing - but it feels like a bit of a hack to load the module in there.

Is there a recommended place to load kernel modules that need rw access to a file?

6
  • Maybe the module only handles reading, not writing. Or the device is set up for read-only access. Or you are mounting read-only. The kernel itself doesn't go messing around like you seem to think.
    – vonbrand
    Jan 17, 2016 at 17:30
  • Thank you for commenting - I'm sorry I didn't make it clear enough: when I load the module later [in rc.local] it works perfectly, and I get readwrite access. I just found this a bit of a hack and was wondering what recommended practice is. Cheers :)
    – Tom H
    Jan 17, 2016 at 23:10
  • I'm pretty sure your hypothesis is false. The read-only or read+write state of the root filesystem should not have anything to do with it because g_mass_storage works with a block device, not with a mounted filesystem (and that block device is presumably not the device that hosts the root filesystem as that would lead to double mounting and file system corruption).
    – Celada
    Jan 17, 2016 at 23:18
  • 1
    It might help if you told us which block device you are feeding to g_mass_storage. Basically, what is the file= parameter you are giving to the module.
    – Celada
    Jan 17, 2016 at 23:19
  • Sure thing - I created a filesystem with "sudo dd if=/dev/zero of=/piusb.bin bs=512 count=2880", then "sudo mkdosfs /piusb.bin". Parameter therefore was file=/piusb.bin.
    – Tom H
    Jan 17, 2016 at 23:23

1 Answer 1

1

A [probably not perfect] solution to this has been to hook onto the "systemd-remount-fs.service" systemd service, which is the remounting of the filesystem to read-write.

This means the module will be loaded as early as possible, whilst still being loaded after the filesystem becomes readwrite.

My sample systemd config file is as follows:

[Unit]
Description=Starts kernel modules for USB OTG
After=systemd-remount-fs.service
DefaultDependencies=false

[Service]
Type=simple
ExecStart=/home/pi/programs/startmod.sh
WorkingDirectory=/home/pi/programs/

[Install]
WantedBy=local-fs.target

This works, if a little hackily.

1
  • Thanks for this! I also needed to load a kernel later in the boot sequence (g_mass_storage too, coincidentally) and this helped me. You can simplify it a little by adding Type=oneshot and RemainAfterExit=yes to the Service definition, and calling ExecStart=/sbin/modprobe g_mass_storage file=/dev/sda directly (and ExecStop=/sbin/rmmod g_mass_storage if you like). In my case, I needed to run it after iscsi.service and set WantedBy=sysinit.target. My full file is here: gist.github.com/tobiasmcnulty/7d649cc5ac0fd39196d11c8aa4595e20 Mar 17, 2022 at 2:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .