I have a ASUS laptop with Fedora 13. My problem is that any USB storage I connect does not automount. I have other computer with Fedora 13 which does not have the problem.
I have not be able to find any difference in configuration between my laptop and other computers that work.
So to try to trace down the problem I started to looomk for documentation on how it was supposed to work. I have looked at udev, devkit, hal , dbus, polkit, gnome and others.
I want to know which events, logs, config files and monitor programs that I can use to track down the events that takes place from when I attach an USB stick and until i have a window up and running in GNOME.
So far I have traced that udev detects the disk and creates /dev/sdb (and /dev/sdb1 for partition 1) and that event about device added is sent as messages on dbus. I am able to mount the disk manually with udisks but not with gnome-disk-utility (palmiset).
There is many different applications involved to automount a disk, I want to find out where in the chain of events does it fail.
I just found the reason it did not mount. I had a leftover file from earlier udev version. File 60-persistent-storage.rules existed in both /etc/udev/rules.d and in /lib/udev/rules.d . The former overruled the last one. When removing the one in /etc/udev/rules.d the USB drives mounted correctly again.
Related
I have a task to make a virtual device under a real one with the help of device mapper kernel module. Virtual device must transfer any request to a real device, so both devices must be equal.
In prospective I should be able to control requests, so I wrote kernel module, representing device mapper target, using this article.
After making module and inserting it (insmod command) I setup my device (dmsetup create). Then do mount and can work with a real device through just created virtual.
But the question is how to repeat above mentioned instructions in boot time? I'd like to use my virtual device as a general one (by changing fstab, I guess).
Thanks in advance!
If you are going to use your device as the root filesystem, you need to create an initramfs that sets it up. Basically a shell script that issues dmsetup commands, followed by a mount and finally pivot_root to the new filesystem.
There was a discussion on the dm-devel mailing list last year on how to do this in the Linux kernel without an initramfs, by specifying mapper lines on the kernel command line. This is they way Chrome OS does it, because they can't/won't use an initramfs. See here for documentation of this feature. The functionality was never merged though.
The patch series was updated and resubmitted in May 2017. Hopefully we will eventually see it merged in some form or other.
If you are not going to use your device as the root filesystem, you can still use the same approach if you want, but there might be easier ways.
I have an embedded linux device running a USB gadget kernel module to make the mmc available to the host PC(such as Windows or Linux).
When I update the file in mmc, it won't sync with host PC unless I rmmod and insmod again. Is there any better way to update new files? And how can I detect a file is modified by host PC? I'm using C programming on my linux device.
Thanks.
(1) There really isn't a better way to update new files. You need to take turns and only access the mmc from Linux or Windows, one at a time.
(2) You can't easily do that.
When you say "When I update the file in mmc", I assume that you have the mmc mounted in the linux device, and are updating files from linux at the same time that Windows has mounted the device. I don't think this is advisable. The host (Windows) may cache file and/or directory information from the mmc, and if the embedded Linux changes that information unexpectedly, it may produce errors from the Windows FS, and could corrupt the mmc.
If you want to share files between the embedded Linux and host Windows, and be able to modify them from either OS without taking turns, an alternative solution would be to use the network device gadget and run Samba file sharing on the embedded Linux side to export the filesystem where the mmc is mounted on the Linux side.
Right now, I'm compiling with printk's, copy the resulting kernel to a USB stick, mounting the USB stick on the device, mounting the partition that contains the kernel, copying the new kernel from the USB stick to the partition, rebooting, then inspecting the trace by capturing the dmesg output to a file.
On workstation:
make my-kernel
cp new_kernel /path/to/usb/stick
On embedded device:
mount /dev/sda1/ /mnt
mount kernelpartition /tmp/kernel
cp /mnt/new_kernel /tmp/kernel
sync
umount /tmp/kernel
umount /dev/sda1
reboot
dmesg > mytrace
less mytrace
Is it supposed to this painful to develop? I don't understand how any meaningful amount of non-trivial kernel code is ever developed.
The best workflow is going to depend on the capabilities of the device you are working with. Often they will have a bootloader with options to boot from a network or serial port.
I'm doing some embedded development also, and here's what I came up with. The device I am working with has some built in flash which by default it boots from, but also has a USB port and an SD Card slot. It has a fairly primitive bootloader.
On the USB port I have connected a wifi dongle. I make sure that I compile the kernels with the needed modules to get the USB dongle up and running.
I have built a minimal kernel and root filesystem which I have flashed onto the device. This kernel has the option CONFIG_KEXEC enabled. The root filesystem has kexec tools. I build the system using buildroot.
When this system starts, it attempts to mount the SDCARD and checks to see if it can find a kernel in the root directory. If it can, then it uses kexec to boot this second kernel. This is done using a custom init script that I have written.
If you don't have an SD Card slot on your device, you could probably do something similar with a USB memory stick.
With this setup, I can just use sftp to transfer a new kernel image onto the sdcard, and kexec to boot it. It saves me the hassle of reflashing the device each time I change the kernel.
I am writing a C program in Linux user space for an HMI. I want to detect the pendrive when inserted into the USB port on my SBC. I am running Lubuntu on it. So it is not having udev libraries. When I try to install udev on SBC, it is asking for dependencies and version compatibility issues are coming. Is there any other way to detect the Pendrive insertion from user space.
When I mount a device ex: /dev/sdc1(pendrive) to a particular folder ex: /mnt/vj, its being mounted properly. If I remove the pendrive without unmounting it then when next time pendrive inserted its being detected as /dev/sdd1 . How to fix the logical name for a pendrive in such cases. I want it to be /dev/sdc1 always. Is it possible?
Thanks in anticipation.
You can implement your own event listening daemon instead of udev. Youhave to create a netlink socket of type NETLINK_KOBJECT_UEVENT. By parsing the events, you will be able to detect the insertion of your drive.
It is not possible to ensure the name is always the same but you can probably create a symlink to the proper block device after detecting the event.
Check the link ubuntu 12.04 libudev-dev won't install because of dependencies that should mostly resolve your udev installation/dependencies issue if related to it.
udev is one of the easiest ways for detecting hardware plug-in and fetching of device information. Checkout libudev that is part of udev (Device manager of Linux kernel). Apart from managing device nodes in the /dev directory while hardware devices are added into the system or removed from it, the udev also handles all related user-space events that are raised during various operations such as addition/removal.
libudev allows access to device information and also provides a monitoring interface like udev_monitor that connects to device event source. udev_monitor_get_fd provides file descriptor that can be used with select system call for monitoring.
Check this link that has information related to usage of libudev http://www.signal11.us/oss/udev/
This might seem like a stupid question but...
After using a USB to install Ubuntu, is it possible to use it as a regular USB again or is it like a CD install and the USB is now only good for installing Ubuntu?
Thanks.
Yes you can.
Infact you can keep the Ubuntu setup as it is and use the remaining free space to store other things, just incase you need Ubuntu installation in future.
You can use it normally, just be sure you have cleaned up the MBR for the case you leave the device plugged in at restart (when USB boot is still enabled).
Easiest is to format the whole partition (or use a partition manager to clean up the whole device). GParted should be able to do this for you.
Some (sketchy!) technical background:
The USB device is a flash device, where bits are stored non-volatile, but eraseable and changeable. Bits at a normal CD-ROM will really be "burned" in as the reflection capacity will be permanently changed when creating a CD. When booting up your computer, there is small memory ROM that contains a bootloader, that is looking up for devices containing a MBR at the first 512 bytes, that will be executed and load the OS (or in your case the first steps of the Ubuntu installation process).
So if you want to use the USB device as normal data storage again, you should also clear up these first 512 Bytes, as the bootloader from the USB could be loaded otherwise when leaving the device plugged in at reboot. Then the bootloader could throw an exception, as it would normally expect the Ubuntu installation files to be present onto this device.