I am trying to boot an appliance to a USB drive and the provided configuration file for the syslinux.cfg file seems to have some error in it. Is there any way to validate a syslinux.cfg file and its syntax or anyone smart on here that might be able to check why this seems to not work? After booting, we received the following error:
SYSLINUX 4.04 EDD 2011-04-18 Copyright (C) 1994-2011 H. Peter Anvin et al
Unknown keyword in configuration file: 1
No DEFAULT or UI configuration directive found!
boot:
This is the configuration we have inside the syslinux.cfg file. I've tried multiple formatting options of my USB drive, including FAT32 and FAT16. I've tried renaming folders as prescribed by other articles (although I don't think there is a file referencing issue, because, because otherwise how would it know that there is an unknown keyword in the configuration file?).
SERIAL 1 38400 CONSOLE 1 default vmlinuz0 initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro liveimg quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 serial text console=ttyS1,38400n8
We are following instructions from a vendor on how to boot to a USB to recover this appliance, but I don't get the strong feeling that they understand what's going on, so I thought I'd see if anyone could weigh in on why it cannot find a DEFAULT or UI configuration directive, despite the "default vmlinuz0" line being right there.
I have created a Linux device driver and can add it to the system (insmod, mknod). When I look in /dev I see it listed as camerax:
ls -l /dev/camerax
crw-r--r-- 1 root root 245, 0 Jun 27 17:19
Even so, I cannot access it. Whatever I do, I get an error.
For example:
int fd = open("/dev/camerax", O_RDONLY);
printf("%d [%s]\n", fd, strerror(errno));
Generates:
-1 [No such device or address]
I'm running as a super user. Any suggestions?
Your Module is not linked to the special file which you have mentioned so it is giving error.
If your module is successfully inserted verify in /proc/devices using cat command
cat /proc/devices.
file created using mknod in the path /dev/____ is just a refrence to your driver
The major and minor number should match with your inserted device.
I have solved the problem.
Instead of creating the major device number dynamically, as described in the documentation, I now set it explicitly to 61. Everything now works.
The only difference I can see between the working and non-working versions is the major number (and yes, I change anything that uses the device number so I am always using the appropriate one).
This adds one more bizarre feature of the system to my growing list.
I’m trying to setup SMACK on my system but am having some strange problems.
I have SMACK turned on in my kernel and have added the line:
smackfs /smack smackfs smackfsdef=* 0 0
to my /etc/fstab file. SMACK seems to be enforcing labelled subject/object access as expected. But when I create new files the files do not have the labels of the creating process. Instead the labels are blank.
My kernel version is 3.4.36. My kernel config includes:
CONFIG_NETLABEL=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SMACK=y
CONFIG_DEFAULT_SECURITY_SMACK=y
CONFIG_DEFAULT_SECURITY="smack"
Found the answer to my own question. The yaffs2 file system that my device runs on does not fully support extended attributes for newly created files.
I am using a command in the proc file system which is the following
echo 0 > /proc/sys/net/ipv4/ip_forward
Note: I don't want to know the basic of the command written above, I want what all happens when it goes inside the kernel. As, I want to implement one of the /proc file.
Now if I want to trace the code right from when the 0 is echoed in the file-system then how to go about it. I mean if I want to trace what happens when I do this.
I want to see where in the kernel code this 0 is accepted and in which value does it get stored inorder to make the changes. Please, can somebody tell what all happens when you call this command. I want in detail explain. I don't want the description of the command.
Any related article on how it changes the kernel parameters is also fine.
I have read this but, not explained there. http://www.linuxjournal.com/article/8381
Thanks
search through linux tree (especially network stack) for create_proc_entry function. Figure out what file creates ip_forward (it must be in ip4v drivers) from name passed to create_proc_entry.
When you find the file, look at where proc_dir_entry structure is created and what functions are assigned to its read_proc, write_proc members.
THE SCENARIO
I'm developing a Root FS for some embedded Linux device. It is sitting on the host, exported via NFS and my development board mounts is under "/".
The workflows that I need are:
- to share my FS to other developers(they have with their own dev. boards)
- to backup my Root FS onto some "server"
- to deploy my Root FS onto flash-disks or other media
- track changes in specific files in my Root FS, branching&merging,roll back etc.
Guys, this seems to me as a Version Control scenario, and I even use git.
THE PROBLEM
As you know Git(and svn/mercurial/bazaar too !) 1) does not store special files (device files under /dev etc.) 2) does not store file owners and permissions.
I want to store everything and AS IS.
THE QUESTION:
Do you know some VCS that will do the job ?
Or may be you know about another (but simple) solution for doing my scenarios ?
IS IT A COMMON PROBLEM...
I believe that it is, because till now I've heard about scripts/hooks/custom soft that everybody(!) works out for his purposes. All I need is an all-eating-VSS
Thank you !!
Having done something similar (developing firmware for an embedded Linux OS), I've found that it's better to put device file creation into a script called by your build system, rather than to store device files directly on the development machine. Then the script that creates the files goes into version control, instead of the files themselves, and (BONUS) you don't need to be root to modify them. Run the build through fakeroot instead.
I suppose this doesn't directly answer your question, but it may be worth thinking about revising your development model. It's NEVER a good idea to run your build as root, because what happens if you accidentally have a "/" in front of a common path? You may inadvertently replace /bin with a whole bunch of links to busybox built for a different architecture.
This is the tool for you:
http://fsvs.tigris.org/
it has svn backend.
I know this seems a little obvious, but as you haven't mentioned it: Have you considered mechanisms to put all your special files into a regular file, like, for example, into a tar archive? You could store that just fine with any version control system, and as filesystems have lots of binary data anyway diffs between two revisions of a full root filesystem aren't that useful anyway, so you might even not lose too many of the features your version control system provides.
initramfs is a good answer to the userid groupid, permissioon problem. In your kernel source directory, there is scripts/gen_initramfs_list.sh.
This script allows you to build an initramfs archive from several sources. You can for example, specify :
a directory : The files and directory found in this base directory will be at the root of your file system.
a file liste : it is a text file, very useful to create directory, files and special device files. See example below
If you develop as non root, and your rootfs is in rootfsdir, then probably the file in rootfsdir are owned by you. gen_initramfs_list can translate your uid, gid into 0, 0. Here is an exemple command line :
gen_initramfs_list -u $MYUID -o initramfs.gz rootfsdir/ device.txt
Where device.txt contains :
# This is a very simple, default initramfs
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
dir /root 0700 0 0
# file /kinit usr/kinit/kinit 0755 0 0
# slink /init kinit 0755 0 0
Then you can use standard version control for your rootfsdir content, and add the device.txt file under version control, and here you are : content and file attribute are versionned :).
I don't know if you can change the permission and uid/gid of a file in a directory source via a filelist source, but this would be a logical feature.
Of course you can start with minimal root fs, from which you mount your existing nfs_export.
It is a common problem, and gen_initramfs_list is the tool to solve it.
Why not just use rsync? Something like rsnapshot (http://www.rsnapshot.org) will do what you want. Alternatively Unison (http://www.cis.upenn.edu/~bcpierce/unison/) is explicitly designed for this - it describes itself as a cross-platform file synchronisation technology with version control, and might be what you need.