Firs, please excuse me - those are my first steps in building OS and using Buildroot.
I've managed to create my first custom os (nothing special, just a first test with patched 4.6.3 kernel with grsec).
I have this files in /output/images dir:
$ ls -lh
total 304M
-rw-r--r-- 1 fugitive fugitive 512 Apr 13 01:01 boot.img
-rw-r--r-- 1 fugitive fugitive 4.1M Apr 13 00:57 bzImage
-rw-r--r-- 1 fugitive fugitive 79M Apr 13 01:01 disk.img
-rw-r--r-- 1 fugitive fugitive 137K Apr 13 00:57 grub-eltorito.img
-rw-r--r-- 1 fugitive fugitive 137K Apr 13 00:57 grub.img
-rw-r--r-- 1 fugitive fugitive 69M Apr 13 01:01 rootfs.cpio
-rw-r--r-- 1 fugitive fugitive 79M Apr 13 02:10 rootfs.ext2
lrwxrwxrwx 1 fugitive fugitive 11 Apr 13 01:01 rootfs.ext4 -> rootfs.ext2
-rw-r--r-- 1 fugitive fugitive 74M Apr 13 01:01 rootfs.iso9660
What my goal is - to create a bootabile iso image, but I don't know how.
I am able to emulate it with qemu, like you can see on the screenshot:
I've tried to burn rootfs.iso9660 to USB drive, but not able to boot.
Tried to rename rootfs.iso9660 to rootfs.iso9660.iso and try with VirtualBox, but then I got a grub terminal.
Appreciate the help and instructions!
EDIT:
.config file:
-bash-4.2$ grep BR2_TARGET_ROOTFS_ .config | grep -v ^#
BR2_TARGET_ROOTFS_CPIO=y
BR2_TARGET_ROOTFS_CPIO_NONE=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_GEN=4
BR2_TARGET_ROOTFS_EXT2_REV=1
BR2_TARGET_ROOTFS_EXT2_LABEL=""
BR2_TARGET_ROOTFS_EXT2_BLOCKS=0
BR2_TARGET_ROOTFS_EXT2_INODES=0
BR2_TARGET_ROOTFS_EXT2_EXTRA_BLOCKS=0
BR2_TARGET_ROOTFS_EXT2_EXTRA_INODES=0
BR2_TARGET_ROOTFS_EXT2_RESBLKS=0
BR2_TARGET_ROOTFS_EXT2_NONE=y
BR2_TARGET_ROOTFS_ISO9660=y
BR2_TARGET_ROOTFS_ISO9660_GRUB2=y
BR2_TARGET_ROOTFS_ISO9660_BOOT_MENU="fs/iso9660/grub.cfg"
BR2_TARGET_ROOTFS_ISO9660_INITRD=y
-bash-4.2$ grep -r BR2_TARGET_ROOTFS_ISO9660_HYBRID *
fs/iso9660/Config.in:config BR2_TARGET_ROOTFS_ISO9660_HYBRID
fs/iso9660/iso9660.mk:ifeq ($(BR2_TARGET_ROOTFS_ISO9660_HYBRID),y)
Have you enabled BR2_TARGET_ROOTFS_ISO9660_HYBRID ? This is needed if you want your ISO image to also work from a USB device.
A bootable ISO image (old school ISO just for CDROMs) with Grub2 - I made it work.
The main hints:
Grub: add builtin modules biosdisk iso9660
Grub: boot partition set to cd
After changing Grub options you need to recompile it (read how to rebuild package in official manual)
If you do changes in kernel config, make sure that CDROM devices and ISO9660 filesystem are supported
If you are in grub rescue console (which is not a good sign), try to execute commands step by step (like in this answer) to figure out the issue.
Extract from .config
I saved my changes as defconfig (make savedefconfig, read here) and here is what you should have in yours:
BR2_ROOTFS_POST_BUILD_SCRIPT="board/pc/post-build.sh"
BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/pc/genimage-bios.cfg"
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
BR2_TARGET_ROOTFS_ISO9660=y
BR2_TARGET_ROOTFS_ISO9660_BOOT_MENU="fs/iso9660/grub.cfg"
BR2_TARGET_GRUB2=y
BR2_TARGET_GRUB2_BOOT_PARTITION="cd"
BR2_TARGET_GRUB2_BUILTIN_MODULES="boot linux ext2 fat squash4 part_msdos part_gpt normal biosdisk iso9660"
BR2_PACKAGE_HOST_GENIMAGE=y
Side note: I started my trials with building a default configuration for PC make pc_x86_64_defconfig && make
Test
Test your ISO in QEMU:
qemu-system-x86_64 -m 512 -cdrom output/images/rootfs.iso9660
It also works in Virtual Box.
Try :
sudo dd if=/path/to/output/images/disk.img of=/path/to/usb/drive bs=1M
To know the path to your usb drive do :
lsblk
and find your usb drive.
Related
I am trying to give myself root access to all the file in this folder and not have to sudo everything I want to run a command.
The file I am concerned with is pro
When I enter ls -l I get :
drwxr-xr-x+ 12 Guest _guest 384 13 Jan 14:56 Guest
drwxrwxrwt 9 root wheel 288 13 Jan 14:30 Shared
drwxr-xr-x+ 148 Santi staff 4736 1 Apr 17:13 pro
then I enter chmod 775 pro/
It doesnt seem to change the permssions. What can I do to fix this or why is the folder restricting permission even though I appear to be root?
drwxr-xr-x+ ...
the final + means that the file is governed by acl
see
apropos acl : give you the mans to consult
wikipedia
Access Control Lists on Arch wiki
I am creating a little experimentation application on my Odroid XU3 with Ubuntu 15.04 Lite.
http://dn.odroid.com/homebackup/201407071058089142.jpg
The device (Odroid) receives midi as input via a keyboard connected via one of the available USB Host ports (this part is OK) and sents some other midi instructions (also via USB, but USB OTG) to the computer to create harmony (this part is not ok).
The use case is :
you play on your midi keyboard some notes, the odroid received them, the embedded application code analyses them, find new notes (midi instructions) and send them to your Windows PC that you can root them to the VST of your choice.
The issue I have is that in order to achieve that, I need the Odroid device to appear as a MIDI keyboard in Windows that people can add the device in their Digital Audio Workstations.
Most of the midi controllers sold on the market have their own drivers but some are class compliant devices.
How can I make Windows detect this Odroid board an a midi keyboard? If I need to write a specific driver for that, from where to start?
Edit : Found g_midi drivers but not usb_f_midi
odroid#odroid:/lib/modules/3.10.72-23/kernel/drivers/usb/gadget$ ls -al
total 628
drwxr-xr-x 2 root root 4096 May 23 21:28 .
drwxr-xr-x 8 root root 4096 May 23 21:27 ..
-rw-r--r-- 1 root root 37544 May 23 21:11 g_acm_ms.ko
-rw-r--r-- 1 root root 17468 May 23 21:11 g_audio.ko
-rw-r--r-- 1 root root 24164 May 23 21:11 g_cdc.ko
-rw-r--r-- 1 root root 44488 May 23 21:11 g_ether.ko
-rw-r--r-- 1 root root 63552 May 23 21:11 g_ffs.ko
-rw-r--r-- 1 root root 16672 May 23 21:11 g_hid.ko
-rw-r--r-- 1 root root 37084 May 23 21:11 g_mass_storage.ko
-rw-r--r-- 1 root root 17468 May 23 21:11 g_midi.ko
-rw-r--r-- 1 root root 69752 May 23 21:11 g_multi.ko
-rw-r--r-- 1 root root 28164 May 23 21:11 g_ncm.ko
-rw-r--r-- 1 root root 35396 May 23 21:11 g_nokia.ko
-rw-r--r-- 1 root root 20944 May 23 21:11 g_printer.ko
-rw-r--r-- 1 root root 9016 May 23 21:11 g_serial.ko
-rw-r--r-- 1 root root 26628 May 23 21:11 g_webcam.ko
-rw-r--r-- 1 root root 11408 May 23 21:11 g_zero.ko
-rw-r--r-- 1 root root 25380 May 23 21:11 gadgetfs.ko
-rw-r--r-- 1 root root 45940 May 23 21:11 libcomposite.ko
-rw-r--r-- 1 root root 15244 May 23 21:11 u_serial.ko
-rw-r--r-- 1 root root 9972 May 23 21:11 usb_f_acm.ko
-rw-r--r-- 1 root root 8060 May 23 21:11 usb_f_obex.ko
-rw-r--r-- 1 root root 6928 May 23 21:11 usb_f_serial.ko
-rw-r--r-- 1 root root 14584 May 23 21:11 usb_f_ss_lb.ko
Second edit : Thanks to CL
Trying the g_midi driver
odroid#odroid:/proc/asound$ cat cards
0 [odroidaudio ]: odroid-audio - odroid-audio odroid-audio
1 [MPK225 ]: USB-Audio - MPK225 Akai MPK225 at usb-12110000.usb-1.2, full speed
2 [K61 ]: USB-Audio - Keystation 61 M-Audio Keystation 61 at usb-12110000.usb-1.3, full speed.
$ modprobe g_midi in_ports=1 out_ports=1
Error :
modprobe : ERROR : could not insert 'g_midi' : Device Or Ressource busy.
Same error with other ports (3,4, etc)
When removing the Midi keyboards :
odroid#odroid:/proc/asound$ cat cards
0 [odroidaudio ]: odroid-audio - odroid-audio odroid-audio
$ modprobe g_midi in_ports=1 out_ports=1
same error :
modprobe : ERROR : could not insert 'g_midi' : Device Or Ressource busy.
Just load the g_midi module:
$ modprobe g_midi in_ports=1 out_ports=1
(1 and 1 are the defaults.)
This will create a class-compliant USB MIDI interface, which is visible on the Odroid like a normal sound card:
$ cat /proc/asound/cards
0 [whatever ]: ...
1 [gmidi ]: MIDI Gadget - g_midi
MIDI Gadget
... and can be accessed with the normal Linux MIDI APIs.
The /sys/class/gpio can only be accessed as root by default. So I like that a new group gpio can use the files and directories under /sys/class/gpio. To achieve that I added the following lines to /etc/rc.local (I'm on Debian):
sudo chown root:gpio /sys/class/gpio/unexport /sys/class/gpio/export
sudo chmod 220 /sys/class/gpio/unexport /sys/class/gpio/export
So this gives write permissions to all the gpio group members. So they can now export and unexport pins fine.
The problem is they can't read/write the specific pin files after export (e.x. /sys/class/gpio/gpio17) beacause those are owned by root:root again.
How can I change that they are created by default as root:gpio too? I mean I can do that manually each time I export a pin. But that's a bit uncomfy.
UPDATE
According to larsks' answer I created the missing rule file. Now it partially works:
-rwxrwx--- 1 root gpio 4096 Jun 19 16:48 export
lrwxrwxrwx 1 root gpio 0 Jun 19 16:51 gpio17 -> ../../devices/soc/3f200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Jun 19 16:45 gpiochip0 -> ../../devices/soc/3f200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jun 19 16:45 unexport
But for the ./gpio17/ I still get root:root:
-rw-r--r-- 1 root root 4096 Jun 19 16:52 active_low
lrwxrwxrwx 1 root root 0 Jun 19 16:52 device -> ../../../3f200000.gpio
-rw-r--r-- 1 root root 4096 Jun 19 16:52 direction
-rw-r--r-- 1 root root 4096 Jun 19 16:52 edge
drwxr-xr-x 2 root root 0 Jun 19 16:52 power
lrwxrwxrwx 1 root root 0 Jun 19 16:52 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jun 19 16:52 uevent
-rw-r--r-- 1 root root 4096 Jun 19 16:52 value
UPDATE 2
Okay I solved the problem. Because I installed Raspbian over the RaspbianInstaller I never went through the raspi-config tool. This seems to be a problem. Because I was also missing the /sys/device/virtual/gpio/ folder.
I followed this guide here: https://community.element14.com/products/raspberry-pi/f/forum/26425/piface-digital-2---setup-and-use#139528
And afterwards the permissions were correct (even for the pin-folders and their files value, direction, ...).
More common rule for 4.x kernels will be the following
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'find -L /sys/class/gpio/ -maxdepth 2 -exec chown root:gpio {} \; -exec chmod 770 {} \; || true'"
The rule in the initial answer will fail to chown the exported gpio if there's a symbolic link in the path
UPD please beg in mind that when you export some GPIO via sysfs, you should wait for udev rule to fire and complete before you get desired access rights. The thing that worked for me was sleep about 100ms before trying to access GPIO files.
You can do this using udev rules, which can define actions to execute when the kernel instantiates new devices. Current versions of the Raspbian distribution for Raspberry Pi devices contain the following in /etc/udev/rules.d/99-com.rules:
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio'"
This ensures that entries under /sys/class/gpio are always available to members of the gpio group:
# ls -lL /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:36 export
drwxrwx--- 2 root gpio 0 Jan 1 1970 gpiochip0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 unexport
# echo 11 > /sys/class/gpio/export
# ls -lL /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 export
drwxrwx--- 2 root gpio 0 May 6 23:37 gpio11
drwxrwx--- 2 root gpio 0 Jan 1 1970 gpiochip0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 unexport
Update
Permissions are correct for individual pins as well:
# ls -Ll /sys/class/gpio/gpio11/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 active_low
drwxr-xr-x 3 root root 0 May 6 23:36 device
-rwxrwx--- 1 root gpio 4096 May 6 23:37 direction
-rwxrwx--- 1 root gpio 4096 May 6 23:37 edge
drwxrwx--- 2 root gpio 0 May 6 23:37 subsystem
-rwxrwx--- 1 root gpio 4096 May 6 23:37 uevent
-rwxrwx--- 1 root gpio 4096 May 6 23:37 value
Expanding on the answer by #roman-savrulin, here's a simpler version.
There's no need to run the rule on REMOVE events, only ADD events. There's also no need to run 'find' as the udev environment will supply the exact path of the sysfs directory containing the new GPIO pin's files. You can also use 'chgrp' to change only the owning group, and symbolic modes in 'chmod' to only add the group-write permission bit.
You'll still have to wait for the completion of the rule processing before trying to open the pin's files, but the process should complete more quickly with a simpler rule which only touches the minimum number of files necessary.
SUBSYSTEM=="gpio*", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys/${DEVPATH} && chmod -R g+w /sys/${DEVPATH}'"
Check the groups you belong to:
userk#dopamine $: groups
userk sudo dialout
If you belong to dialout the following, if not, comment.
userk#dopamine $: ls -l /dev/gpiomem
crw------- root root /dev/gpiomem
This file mirrors the memory associated with the GPIO device. The output of the command means that the owner of the file is the root user and the group that "owns" it is the root group. The 10 characters represent the file type and the permissions associated with it. The current configuration allows the owner of the file to read and write to the file.
You want to be able to read and write that file if you want to control the gpios.
One option would be to modify the group owner and make it match with the one you belong to (dialout in my case) and set the permissions in order to allow all users of that group to read and write the file.
Long story short:
userk#dopamine $: sudo chown root:dialout /dev/gpiomem
userk#dopamine $: sudo chmod 660 /dev/gpiomem
Wait! This setting won't be persistent and will vanish after reboot.
See this post for further info about the topic
For Ubuntu run.
sudo apt install rpi.gpio-common
I'm running Max OSX 10.9.3 and I'm trying to setup an SSHFS file-share between my MacBook Pro and a remote file system. However, when I try to do it, it doesn't work.
Strangely enough, it makes the target directory disappear. Has anyone else seen this happen? Is it a bug?
First see that I can ssh normally into the target machine:
% ssh remoteuser#XXX.XXX.XXX.XXX # <--- SSH to remote system works! See below.
remoteuser#XXX.XXX.XXX.XXX % ls -altr remoteDir
total 8
drwxr-xr-x 26 remoteuser remoteuser 4096 Jun 22 01:00 ..
drwxrwxrwx 2 remoteuser remoteuser 4096 Jun 22 01:08 .
remoteuser#XXX.XXX.XXX.XXX % exit
% # <--- Logged out of remote system
Next, I create a directory locally and verify it was created:
% pwd
/mnt
% ls
total 0
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 2 root admin 68 Jun 23 08:11 ./
% sudo mkdir share1
% ls
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 4 root admin 136 Jun 23 08:50 ./
drwxr-xr-x 2 root admin 68 Jun 23 08:50 share/
Now I try to setup the SSHFS share:
% sudo sshfs remoteuser#XXX.XXX.XXX.XXX:remoteDir /mnt/share1
remoteuser#XXX.XXX.XXX.XXX's password:
%
Ok. It seems to have worked. No errors. So let's see the share we created, shall we?
% ls
ls: share1: No such file or directory
total 0
drwxr-xr-x 31 root admin 1122 Jun 18 18:34 ../
drwxr-xr-x 3 root admin 102 Jun 23 08:12 ./
What? Not only is the File Sharing not working, but the share1 directory seems to have vanished! (Although the file system seems to know it is missing, which is weird).
Where did /mnt/share1 go and how do I setup this SSHFS?
SSHFS doesn't come with OS X AFAIK, so you should mention how you installed it. But I'm guessing sshfs is designed to be used with fstab or mount rather than be called directly. Try something like:
mount -t sshfs remoteuser#XXX.XXX.XXX.XXX:remoteDir /mnt/share1
Hi I have created an aplication myprogram.app file. Now I want to create Drag and drop DMG file for that application. Skype and other software does the same thing.
How to create Drag and Drop DMG file foe my application.
Thanks
Sunil Kumar Sahoo
It's actually pretty easy. You just need to compose some hidden files. Easy way to do this is to just copy someone elses and change to suit your app.
For example, if I mount the MonoDevelop DMG, then I see:
atom:MonoDevelop fak$ ls -al
total 40
drwxr-xr-x 8 fak staff 340 Nov 4 14:03 .
drwxrwxrwt# 10 root admin 340 Nov 10 21:33 ..
-rw-r--r--# 1 fak staff 12292 Nov 4 14:03 .DS_Store
d-wx-wx-wt 2 fak staff 68 Nov 4 14:03 .Trashes
drwxr-xr-x 3 fak staff 102 Nov 4 14:03 .background
drwx------ 4 fak staff 136 Nov 4 14:03 .fseventsd
lrwxr-xr-x 1 fak staff 13 Nov 4 14:03 Applications -> /Applications
drwxr-xr-x 3 fak staff 102 Nov 4 14:02 MonoDevelop.app
Here we see .background that is a directory with a PNG file (the background). The app itself (MonoDevelop.app) and a link to /Applications.
The .DS_Store contains the window size, icon positions, etc. Just setup a directory and use the .DS_Store from it.
There's really not any magic to this. You can create a disk image with Disk Utility. Put the stuff on it that you need, and then convert it to a compressed read-only image (again, with Disk Utility).
For some tips on prettying up the appearance of the window, check out this question. If you need to automate this process, check out this other question for some ways to do that.