Tag Info

New answers tagged

0

I was able to resolve this by simply deleting /etc/udev/rules.d/70-persistent-net.rules and rebooting.


0

EDIT: After a small troubleshooting session with OP I'm modifying the answer to remove the quotes for "biosdevname" Edit the following lines in /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_CMDLINE_LINUX="" To: GRUB_CMDLINE_LINUX_DEFAULT=biosdevname=0 GRUB_CMDLINE_LINUX=biosdevname=0 Next, run sudo update-grub and then reboot. After this, you ...


0

Just to add to @alextartan's answer. I rolled my own backup system which uses USB drives for targets. I need to be sure what's going where. Since UUID's are not particularly user friendly, I rely on disk labels. UUID's are also a bit problematic because whenever you reformat a partition, it gets a new unique UUID, so any scripts using that UUID have to be ...


5

While accessing it by /dev/sdXy is risky, a more accurate identification may be done by UUID. Since you mention (at some point) changing the usb stick, to maintain compatibility, you may want to identify your usb stick by a label. To do so, you can: /dev/disk/by-label/YourLabelHere. Note that you need to set the label to a new usb stick before running the ...


3

This is how I address this problem, but generally as Sato Katsura told you, you need to write a udev rule. Plug in your device, check which device it got (for example by watching dmesg). As superuser call udevadm info --query all /dev/sdc (or whatever). Setup a udev rule, here is an example for my pocketbook. The fields ID_SERIAL_SHORT and ID_FS_UUID I ...



Top 50 recent answers are included