I know that the **eject** command can be used to eject almost any hardware component attached, but can it be used to eject USB drives? Is it possible to eject USB drives and external HDD's with the **eject** command?

I have a laptop without an internal hard drive. To get some use out of it, I'm considering putting the root partition on external media, over USB. I can't see any reason this wouldn't work, but I wonder what would happen if I accidentally disconnected and reconnected the USB. Obviously in general it's possible to reconnect devices automatically, but if the root partition disconnects, would this still be possible? I am pretty sure that a running system would not immediately die if the root were to disappear, but I would not be surprised if remounting became impossible.

I'm still relatively inexperienced in Linux and this is my first post here. I configured mdadm raid 10 far acording to archlinux RAID wiki page but with custom chunk size 64K. It contains 2 older identical hdds intended for use as data (documents, music, photo, movies, conf. backup and so on). I formated this raid to ext4 and added raid's filesystem UUID to fstab and mounted it as /home/dmk/data. Then I chown 1000:1000 the mountpoint. I'm on opensuse tumbleweed with KDE. In dolphin this data raid volume shows as removable, which is not desirable because I want to redirect user directories to my data raid and don't want an accidental disconnection when system runs. But in KDE plasma system tray, disk and devices, there is no removable device listed. Maybe it's only dolphin bug or what. So, I want to get rid of this remove option. I was looking in the dolphin settings with no luck, otherwise I think it's a linux issue. Can you please help me find a way to fix it and find a cause of this behavior? Edit: I have linux on 60G partition of 480G intel ssd and I formatted the rest of drive as data fast partition mainly for steam game data. This partition correctly shows in Dolphin as non removable. Edit 2: Here is my fstab:

UUID=a08f9faa-8142-415c-9ed7-6705237012b1  /                       ext4  defaults      0  1
UUID=b7d0abb1-cf05-45a7-ad4b-2ad4e3a68924  /boot                   ext4  data=ordered  0  2
UUID=84a98554-62fa-4582-b7d6-87a7ccd29ae7  /home/dmk/data\040fast  ext4  data=ordered  0  2
UUID=9d9edf73-fd37-49c9-aa3c-644113183558  /home/dmk/data          ext4  data=ordered  0  2

I have a small bootable system which requires access to storage devices, but not at the data level (i.e. just firmware commands), with the exception of a USB floppy drive whose data is accessed raw (no filesystem, just dd). Problems are generated from this behaviour as: - Some storage devices are locked which causes firmware errors when read operations are attempted - The seeking of the USB floppy is not required and prolongs the boot process I've tried the following commands:

systemctl disable systemd-udev-trigger.service
systemctl disable systemd-udevd.service

systemctl mask systemd-udev-trigger.service
systemctl mask systemd-udevd.service

systemctl stop systemd-udev-trigger.service
systemctl stop systemd-udevd.service

This however results in no block device being created upon the connection of any devices. I understand that udisks2 may once have been used, however it is not present on my particular system. It looks like blkid might be responsible for the access of block devices as I read that it attempts to "locate/print block device attributes". If this is the cause then I'm unsure how to disable it. Solutions requiring hardcoding of block devices (e.g. /dev/sda) are not possible as I don't know what designation the devices be given. It looks like this question may be related to the issue(s) I'm having, but its solutions involve kernel modification which, if it's getting into all that, I'd rather just put up with the extra ten or so seconds and irritating repetitive floppy seek noises! How might these read operations be prevented whilst still being able to access the device as a block device? Thanks

I am attempting to store some large files and I thought an encrypted ext4 partition would be excellent. However the GNOME Disk Utility appears to state ext4 as for internal disks and xfs only for Linux filesystems. Can I utilize them both safely with removable media? Is there one that is more utilitarian for this usage? What makes them different? _________________ Thank you so much for any information you can provide.

Sadly the issue reported and described here: https://unix.stackexchange.com/questions/149029/pernicious-usb-stick-stall-problem-reverting-workaround-fix and https://unix.stackexchange.com/questions/474216/is-writeback-throttling-a-solution-to-the-usb-stick-stall-problem continues to be unresolved in modern Linux distros as of 2024 despite the availability of the BDI interface introduced in Linux 6.2 released in February 2023. This can be addressed by a simple udev rule invoking a script which sets sane writeback cache values for USB mass storage devices.

I have up-to-date Arch Linux with KDE Plasma installed on SSD inside external USB enclosure. The problem is that the volumes of this drive are displayed in system tray with options to safely remove them. This seems pretty useless, so is there any elegant way to make them not to show there? If this matters, the drive is Samsung 840 Pro and the enclosure is one of those based on ASM1351 chipset. The drive in enclosure is handled by uas driver in the system. cat /sys/block/sdb/removable returns 0 (sdb is the subject drive). The volumes, which are displayed in the tray are mounted at / and /home. The system is booted in UEFI mode, and what's interesting is that the ESP (EFI System Partition), which is mounted at /boot, is not shown in system tray. I switched to UEFI boot only recently, and noticed, that before the switch, the /boot was shown in system tray among the other volumes. Not sure, however, if this info is helpful. None of these volumes are shown in system tray when the drive is connected to the mobo using regular internal SATA interface.

I've added the following line to my /etc/fstab to mount a ramdisk. none /media/ramdisk tmpfs nodev,nosuid,noexec,nodiratime,size=2048M 0 0 It shows up in my desktop as a removable drive, and it is shown as such in the status bar and in the dock, as shown below. > > How can I disable this? Should I mount it with different options? Do I have to tweak some desktop settings? I know that I could solve this by disabling the relative extensions, but I want "true" removable drives to show up there. I don't think its related, but I'm using GNOME 44 on Fedora 38.

I have several menuentries in my **grub2** menu, some of which point to removable devices (Ventoy, Windows, etc). Is there any way to configure grub to automatically and temporarily hide (or grey out, or mark) the menuentries for which the device/partition/label they point to is unavailable? I was unable to obtain any information regarding this, so I suppose the answer will likely be a resounding "not possible," but...

In my question https://unix.stackexchange.com/q/119243 I got stuck on a problem nobody else seems to be having. (The issue also impedes my desire to use this answer .) So I made that specific problem into this new question. Apparently removable devices listed in /sys/block end with 1. It is stated here and several other places in this site and this principle is used in the answers I referenced above. My removable device, a Sandisk 64GB flash memory stick, is listed as: /sys/block/sdl/removable:0 Apparently, removable devices should end in 1 (and my others do). Why does my USB memory stick not follow the rule? It was automounted by Dolphin. I'm running Kubuntu 12.04. Dolphin shows it as "59.6GiB Removable Media". And it is mounted (automatically) at /media/me/70E8-1567 sudo blkid shows it as: /dev/sdl1: UUID="70E8-1567" TYPE="vfat". lsblk -do name,rm shows: sdl 0 And lsusb -vv shows: Bus 001 Device 008: ID 0781:5530 SanDisk Corp. Cruzer Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0781 SanDisk Corp. idProduct 0x5530 Cruzer bcdDevice 2.01 iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1

While installing ChromeOS Flex into a machine, the installation process froze and we had to stop the installation. Now, the USB is not recognized in any machine, no matter if Windows or Linux. When executing df -h, the device does not show up. However, it does show up when executing lsusb as Bus 001 Device 008: ID ffff:1201. Additionally, on Ubuntu 20.04, I've tried using GParted, but the device is not detected. However, it does appear in Disks. As you can see, I can't perform any action on the device through Disks. Is there any solution to this? How can the USB be recovered? Thanks in advance.

I have put a CD into my drive. How can I find the rainbow book color on Linux (Red book/Yellow book/Blue book/...)?

I am trying to install a USB memory stick as a (grub2) multiboot and am having trouble booting the Windows installer. Arch Linux doesn't work either, only with KDE neon everything works. I would prefer the Windows as an "iso" file.
Is there a way to run grub-mkconfig on the USB stick? **USB-Stick:** fdisk -l /dev/sdb && lsblk -pf /dev/sdb Disk /dev/sdb: 7.48 GiB, 8021606400 bytes, 15667200 sectors Disk model: USB storage device 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: gpt Disk identifier: 0000-UUID-0000 Device Start End Sectors Size Type /dev/sdb1 2048 206847 204800 100M EFI System /dev/sdb2 206848 15667166 15460319 7.4G Microsoft basic data NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT /dev/sdb ├─/dev/sdb1 vfat EFI 1111-UUID-1111 └─/dev/sdb2 ntfs BOOT 2222-UUID-2222 I installed the USB stick as described in the GNU GRUB manual grub-install --efi-directory=/mnt/EFI --boot-directory=/mnt/BOOT --removable I have unzipped the Windows10.iso and copied it on the USB stick. **grub.cfg:** search.fs_uuid 2222-UUID-2222 root hd0,gpt1 set prefix=($root)'/grub' configfile $prefix/grub.cfg menuentry 'Windows 10' --class win10 { search --fs-uuid --no-floppy --set=root 2222-UUID-2222 chainloader (${root})/win10/bootmgr.efi } menuentry "KDE neon GNU/Linux" ---calss neon { set isofile="/iso/KDEneon.iso" loopback loop (${root})$isofile linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject initrd (loop)/casper/initrd } --- EDIT --- I moved the contents of the "win10" folder to "/" and now the Windows installer boots with this strings: search.fs_uuid 2222-UUID-2222 root hd0,gpt1 set prefix=($root)'/grub' configfile $prefix/grub.cfg menuentry 'Windows 10' { chainloader (${root})/efi/boot/bootx64.efi }

How to avoid any type of partition probes when a HDD is detected by a booted up system, in a way that it only detects basic drive features as model, sector size and capacity, consequently creating just one device file as /dev/sda? Is it a libata/kernel issue? It's about a data recovery experience with a damaged HDD that sectors corresponding to partition table should not being read. I'm not talking about auto-mount, it's already disabled. The sectors linked to partitions are on a scratched area. When heads pass over there, drive crashes. This is what happens when a healthy HDD is attached: **Dmesg Output** Oct 13 16:21:42 wks-01 kernel: [ 906.796660] sd 8:0:0:0: [sdb] 1953525167 512-byte logical blocks: (1.00 TB/931 GiB)... Oct 13 16:21:42 wks-01 kernel: [ 906.915646] sdb: sdb1 (I need to disable that last routine) **Udev Output** KERNEL[906.915935] add /devices/pci0000:00/0000:00:1d.7/usb8/8-3/8-3:1.0/host8/target8:0:0/8:0:0:0/block/sdb (block)
KERNEL[906.915999] add /devices/pci0000:00/0000:00:1d.7/usb8/8-3/8-3:1.0/host8/target8:0:0/8:0:0:0/block/sdb/**sdb1** (block) (**I need to disable this routine)** ...
UDEV [907.392087] add /devices/pci0000:00/0000:00:1d.7/usb8/8-3/8-3:1.0/host8/target8:0:0/8:0:0:0/block/sdb/sdb1 (block)

After installing and configuring Thunar Volume Manager for Arch Linux it doesn't mount any USB devices automatically: $ thunar thunar-volman: Unsupported USB device type. thunar-volman: Unsupported USB device type. thunar-volman: Could not detect the volume corresponding to the device. thunar-volman: Could not detect the volume corresponding to the device. (Both messages are printed twice when inserting a single USB drive.) Polkit seems to be running as expected : $ loginctl show-session $XDG_SESSION_ID Id=c1 Timestamp=Tue 2013-11-19 20:54:41 GMT TimestampMonotonic=33281762 VTNr=7 Display=:0.0 Remote=no RemoteUser=root Service=slim Scope=session-c1.scope Leader=308 Audit=0 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=username There are a bunch of random tips in this thread , but at least some of them seem at odds with the wiki: gvfs is mentioned, although the wiki only mentions it as a requirement for browsing remote locations . Manual mounting works fine: $ sudo mount /dev/sde1 /media/foo $ mount | grep sde1 /dev/sde1 on /media/foo type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

Somehow I can see the sd-card in gnome-disks as /dev/sda, but it won't show up in gparted. In gnome-disks it shows as a mass storage device with no media, or size, and it won't allow me to edit anything.

Even after many years, I'm still an 'arms-length' user of linux. I switched to Mint when XP stopped, use the default configuration, and have not had to interact with Grub before. I use it to get the job done (office and python), rather than fiddling with the OS if possible. I do fiddle with the hardware though. Colleagues keep telling me to 'try different distros', and as I've been running Mint for a few years, thought I would see if there was any significant difference. However the slow experience of running one off a stick does not make for a fair comparison. I happen to have a pile of discarded SATA HDs from previous desktops and the kids' discarded/broken laptops. I bought a cheap eSATA PCI card, so that I could switch HDs without opening the case, and there would be something expendable between me and my mobo when plugging a different HD in. The idea was to install different OSs on different discs, and use the BIOS to boot the one I wanted. I installed a different flavour of Mint on the first HD, and that all seemed to work OK. In the BIOS, I could choose to boot from my normal SSD with Mint 20.1, or the external HD, and all was well. With the external HD removed, it just booted to my SSD. Then I installed Kubuntu 20.04 to another HD. It chose to put both the external disc and the SSD into a grub menu, with it first. This is OK with the disc attached, I can boot into either from grub. However, if I remove the external HD, and tell the BIOS to boot the SSD, I just get a grub shell prompt, no menu of options, so it sounds like it put the important stuff on my removable drive and changed the boot data on the SSD. How would I confirm whether this guess is correct, or indeed find out what happened? If this is correct, is it possible to move the grub business files to my internal SSD, and if I do that, will grub handle the external drive being missing without error, and behave correctly when different external HDs are present? A nuclear workaround springs to mind, which is to nuke and rebuild with only the internal SSD there. I have good backups so it's only time and hassle. Then when I install different OSs to external HDs, to unplug my SSD so there's only the install and the target media in the machine at the time. Will either of these work? I guess what I'm trying to do is a sort of hardware VirtualBox. I have used that, but it's substantially slower, and I'm distrustful of the layers of configuration that I have to set.

I bought this device a few days ago, and checked it with utility f3. It is ostensibly a Philips 256 memory stick, internally seen as an Bus 002 Device 034: ID 090c:2000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) It appears genuine. Yesterday, I was in the middle of copying my video library onto it, when it fell over. Now, whenever I insert it, it persists for a few minutes, and then vanishes. This happens both on my desktop and my laptop machines. I extracted a section of my syslog> I suspect a file corrupted the device, but cannot delete anything. I would like to reformat it, but do not know how. What should I try? I am running Linux Mint 19.1. Is there any other information I might seek out?

Some RAM pci-e card were manufactured https://linustechtips.com/topic/1118940-wtf-is-this-thing-ram-on-a-pci-card/ Say I got a removable 16gb version of this card that is available 95% of time (eg: down for 1 period of 15 minutes in 4 hours). Could Linux take advantage of this extra 16gb of PCI-RAM in a host that already have 16gb (non upgradable) ? How much tweaking should be made to a typical installation? Of course it won't go offline abruptly, a signal will be sent to the host. The time and duration of interruption will be decided by user. Solution 1: As user expects the machine to be "paused" until the PCI-RAM is plugged again, I thought of going to hibernate mode. If the content of PCI-ram is preserved is it just a matter of going to hibernate mode, remove pci, replug pci, wake up ? Solution 2: Another solution would be to write all the content of ram to the local SSD before the PCI-RAM is removed. How could I achieve that ? Mount 2 swap partitions and give priority to the 16gb PCI swap ? And unmount/remount the swap when the pci is turned off/on ?

I have quite a bit of removable media (flash drives, external hard drives, etc) that I want to adjust auto mount options for. How does one do this? Is there something similar to /etc/fstab?