Im using AoE disk for a particular Linux installation.
I need to tell to linux system to see /dev/etherd/e0.0 as a /dev/sda,
im already create a hard link of /dev/etherd/e0.0 to /dev/sda an it works.
But now i need to make system see the /dev/sda (/dev/etherd/e0.0) in /proc/partitions.
There exists a command to do that ?
thank you.
There is no way to do that. The /dev/sda node is reserved for devices which are accessible using the SCSI/SATA/IDE disk driver; AoE devices do not use that mechanism, so they will always show up differently. Creating a hard link will just confuse matters; doing so is inadvisable.
I'm not 100% certain whether it's even possible to boot a machine over AoE. It might be possible to do directly if all the configuration is automatic, or can be performed by setting kernel command line parameters; chances are that you will need to create a custom initrd to initialize the network and bring up the volume.
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.
First off, my intention is to create a portable, bootable USB drive containing a GNU/Linux distribution. Specifically, I want to use Arch Linux with a squashfs read-only root filesystem.
The squashfs image is based on a snapshot of a working VM. The base system with it's services like ssh work out of the box as expected. But when trying to launch gnome via systemd (systemctl start gdm), all I see is a black screen (supposedly the X-Server started but gdm fails to load). I already tried to figure out whats happening, but failed to identify the exact problem.
Home directories are writeable
/tmp is writeable
/var/log is writeable
/var/run & /run are writeable anyway
/var/log/gdm gets created but stays empty.
Which modules may require write access to any other files? Is there any documentation? What would make sense to strace or similar?
My desire is to know the root of the problem and fix it, instead of using workarounds like unionfs. Thanks for any help or hints!
Although it's not relevant, for those who might wonder why I want to do this, here are some points to consider:
Stability - as you cannot modify system files, you cannot mess up the system (unless you write bogus directly to the drive of course)
Storage - as files are compressed, more data fits on the drive
Performance - as I/O on most USB drives is slow, compression gives you higher I/O speed
Portability - no special treatment for read-only storage, you might copy it on a CD or any other read-only technology and it will still work the same way as it would on a writeable disk
Update
I figured out that the problem was actually at /var/lib/gdm. GDM tried to access files in there an (silently) failed doing so giving me a black screen.
I figured out that the problem was actually at /var/lib/gdm. GDM tried to access files in there an (silently) failed doing so giving me a black screen.
journalctl was the debugging command i was missing in the first place.
I would like to create a RAM disk programmatically using Node.js, no matter what the underlying OS is (OS X, Linux and Windows should be supported).
What is the best way to achieve this?
Of course I can run a command as a child process, but I would need to write this code individually for each OS. For obvious reasons I'd like to avoid this.
Is there a better approach (even a module that does it would be fine)?
In a low level and uncommon operation like this, there is no standartized way to generate a RAM disk, it is platform dependent and hence there is no functionality of this in NodeJS and there won't be likely, you have to write an extension. In Windows, it will call ramdisk.exe (not so familiar with it) and on Linux it is availalbe under /dev/shm , which you can resize by mount options later. So, the best way is to find the best external program for Windows versions, and in Linux just mount and use the /dev/shm like a normal folder.
More Info on /dev/shm
Is it possible to mount a ISO image from USB disk and to use it as a filesystem at boot time(with grub)? I ask it because I would like to put the kernel linux image and an ISO to be used as a filesystem(with fedora bootstrap) into an USB disk(without creating new partitions, etc.), as it is possible to do by using Qemu, for example.
Qemu is a virtualization/emulation environment. Grub is a bootloader, designed to get a kernel loaded into memory and start it executing. Neither program is directly related to your question, although you could certainly use Qemu to execute a VM that uses Grub to start Linux to do what you want.
Modern Linux distributions create an initrd, which the bootloader puts into memory for the kernel to use as its initial root file system. The initrd does things like loading the modules necessary to access the hard disks where the real root file system lives. In your case, you should look at having the initrd find your ISO, mount it, and use it as the root.
The contents of initrd vary based on what distro you're using. I'd grab a livecd from somewhere, dump its initrd's contents with zcat /boot/initrd-2.6.whatever.img | cpio -id, and check out what it's doing. Look for the init file, which will be the first user-space process run by the kernel.
Grub's loopback feature should allow you to boot a kernel and initrd from within an ISO image. Unfortunately, there's no way to allow the kernel to mount a loopback device as the root filesystem, so I think you're out of luck.
What are the ways to communicate with a kernel module from user space? By communication i mean sending information and commands between the kernel module and a user space process.
I currently know of two way:
open/close/read/write/ioctl on published device node.
read/write on exported and hooked /proc file.
More specifically, can someone advice the best way to communicate with a kernel module that does not actually drives any hardware and therefore should not be littering /dev with stub nodes that exists solely for ioctl calls? I mostly need to check its various status variables and send it a block of data with a request type tag and see if the request succeeded.
Netlink sockets are designed for that kind of requirements, too...
Also see
man 7 netlink
libnl - Netlink library
The libnl Archives
There's also the /sys filesystem (sysfs):
Sysfs exports information about
devices and drivers from the kernel
device model to userspace, and is also
used for configuration.
(from Wikipedia)
You could also read/write from /dev device nodes.
IMHO, /dev is already littered with stuff and adding your own nodes there isn't a big issue. Don't forget that you can have lots of ioctl codes for a single device node, and the ioctl paramters are passed by reference so can be as big as you like.
Third one is add a new syscall, but the two you have written are the preferred ones, I think. I've found this document that might help, but I still think this option is unadvised: http://www.csee.umbc.edu/courses/undergraduate/CMSC421/fall02/burt/projects/howto_add_systemcall.html
Another acceptable option might be sharing memory.
You could also use Shared Memory and IOCTL
debugfs is another good possibility for APIs that are less stable than sysfs, but the API is basically the same. Here is a minimal runnable example.
configfs is another one. It allows easy dynamic creation of kernel objects from userspace through the filesystem: https://www.kernel.org/doc/Documentation/filesystems/configfs/configfs.txt
In any case, you will have to dirty some namespace... a filesystem entry in case of sysfs and debugfs. Just choose your poison.
Also, udev rules make /dev very similar to sysfs and debugfs: How to create a device in /dev automatically upon loading of the kernel module for a device driver?