I play to self-study 6.001 with the video lectures and lecture handouts. However, I have some problems setting up MIT Scheme in Ubuntu (intrepid).
I used package management and installed MIT-Scheme, but it's obviously the wrong version to use. It should be 7.5.1 instead of 7.7.90
I followed the instructions from this website (http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-001Spring-2005/Tools/detail/linuxinstall.htm)
So far, I've downloaded the tar file, and extracted to /usr/local. I have no idea what step 3 means.
Then I entered command
scheme -large -band 6001.com -edit
and the error is
Not enough memory for this configuration.
I tried to run under sudo mode, and this time the error is different
Unable to allocate process table.
Inconsistency detected
I have close to 1GB of free memory, with ample HDD space. What should I do to successfully set this up?
Step 3 means that you should type export MITSCHEME_6001_DIRECTORY=${your_problems_path}. If you don't want to type it every time you launch Scheme, you should put it as a string in your ~/.bash_profile file(in case you use bash)
About the problem itself, Google instantly suggests a solution:
sudo sysctl -w vm.mmap_min_addr=0(taken from http://ubuntuforums.org/showthread.php?p=4868292)
Instead of the package manager, you may also want to compile the portable C sources for Unix. I am using it happily.
Related
Background
Ubuntu 21.10 can load on my computer through secure boot, and the shim version is 15.4. Then refer to the official tutorial, I installed rEFInd v0.13.2 (the latest version when I posted this blog) via PPA in Ubuntu 21.10. However, when I restart the system and load rEFInd, it always fails with the message Verification failed:(0x1A)Security Violation. I'm sure that both refind_local.cer and refind.cer under the EFI/refind/keys/ have been enrolled through MokManager (Although only refind_local.cer is needed through PPA installation).
Cause
From this post, I got that rEFInd currently (v0.13.2) lacks the .sbat section. For shim 15.3 and later versions, SBAT is mandatory, resulting in failure to start rEFInd.
The post also indicates that the author of rEFInd is currently studying how to solve the related problems. I hope the later versions can fix this issue.
Solution
To conclude, you need to use shim 15 to solve this problem. For this purpose, you can perform the following steps (applicable to amd64. Steps are also similar if you are on other architectures):
Obtain MokManager and the shim efi file signed by Microsoft from Ubuntu launchpad. To achieve this, download shim_15+1552672080.a4a1fbe-0ubuntu2_amd64.deb and shim-signed_1.45+15+1552672080-064ubuntub_bed64.deb.
Unpack the downloaded shim_15+1552672080.a4a1fbe-0ubuntu2_amd64.deb and take out the mmx64.efi file. (data.tar.xz-> . -> usr/lib/shim/mmx64.efi)
Unpack the download shim-signed_1.45+15+1552672080.a4a1fbe-0ubuntu2_amd64.deb, take out the shimx64.efi.dualsigned file. (data.tar.xz-> . -> usr/lib/shim/shimx64.efi.dualsigned) Rename it to shimx64.efi.
Go to download refind-bin-0.13.2.zip. Then create a new folder, and put the two files taken out together with the downloaded zip file into the new folder.
Open terminal in the fore-mentioned folder, then execute the following commands:
unzip refind-bin-0.13.2.zip
cd refind-bin-0.13.2
sudo ./refind-install --shim ../shimx64.efi
If you encounter any confirmation during the installation process, just enter y to confirm.
After restarting, if it prompts Verification failed, refer to step 9 of the official tutorial. Select Enroll key from disk, and then select the ESP disk where you installed rEFInd. Finally, choose the file of path EFI/refind/keys/refind.cer to import.
If you use a non-Ubuntu Linux system on your computer, you can continue to import the cer files corresponding to your distributions in EFI/refind/keys as above. Failure to do so may cause your Linux distribution to be unable to boot via rEFInd.
Today I encountered a "Text file busy" error when trying to overwrite a running program I made with a newer version.
I thought that UNIX like systems don't automatically lock up running files, so package managers like apt can upgrade those software, even if they are running services.
https://en.wikipedia.org/wiki/File_locking#In_Unix-like_systems
Am I wrong in my understanding?
My environment is Ubuntu, and I use the XFS filesystem.
The Text file busy error in specific is about trying to modify an executable while it is executing. The "Text" here refers to the fact that the file being modified is the text segment for a running program. apt can change file but not edit it
Currently I'm experimenting with the Cell/BE CPU under Linux. What I'm trying to do is running simulations in the near future, e.g. about the weather or black holes.
Problem is, Linux only discovers the main CPU of the Cell (the PPE), all other SPUs (7 should be available to Linux) are "sleeping". They just don't work out of the box.
What works is the PPE and it's recognized as a two-threaded CPU with one core by the OS. Also, the SPEs are shown at every boot (with small penguins showing a red "PPE" in them), but afterwards are shown nowhere.
Is it possible to "free" these specialised cores for use by the Linux OS? If so, how?
As noone seems to be interested or can answer this question I'll provide the details myself.
In fact there exists a workaround:
First, create an entry point for the SPUFS:
# sudo mkdir /spu
Create a mount point for the filesystem so you won’t have to manually mount after a reboot. Add this line to /etc/fstab
spufs /spu spufs defaults 0 0
Now reboot and test to make sure the SPUFS is mounted (in a terminal):
spu-top
You should see the 7 SPEs running with 0% load average.
Now Google for the following package to get the runtime library and headers you need for SPE development:
libspe2-2.3.0.135.tar.gz
You should find it on the first hit. Just unpack, build, and install it:
./configure
make
sudo make install
You can ignore the build warnings (or fix them if you have obsessive compulsive disorder).
You can use pkg-config to find the location of the runtime and headers though they are in /usr/local if I recall.
You of course need the gcc-spe compiler and the rest of the PPU and SPU toolchains but those you can install with apt-get as they are in the repos.
Source: comment by Exillis via redribbongnulinux.000webhostapp.com
I am trying to install Xen on Centos6.5 based on this tutorial (http://wiki.centos.org/HowTos/Xen/Xen4QuickStart), however after installing xen and running the script to edit the grub.conf, i am not able to boot into the new kernel.
I get an error stating -
invalid magic number: 9090
Error 13: Invalid or unsupported executable format
Can someone help me please?
Current suspicion: http://wiki.centos.org/HowTos/Xen/Xen4QuickStart definitely not a 10 minute install for all platforms???
History: there is a Centos Bug on this: centos.org/print_bug_page.php?bug_id=6503
I repeated a similar process:
(1) Install Centos 6.6 (Centos kernel: 2.6.32-504.el6.x86_84) from DVD1, DVD2 with Install using only the CENTOS Repo
(2) Installed Xen (Xen4CentOS kernel:3.10.56-11.el6.centos.alt.X86_64) Issuing the following commands from the centos command line (as root, warnings from readers accepted as correct from a security standpoint) To abate the security concern, no network connection existed as an offline repo would have been used but was not actually needed for the Centos minimal install.
yum install centos-release-xen
yum install xen
/usr/bin/grub-bootxen.sh
from the Xen/Centos reference: http://wiki.centos.org/HowTos/Xen/Xen4QuickStart
I noticed that the /boot/grub/grub.conf file was non-existent and tried to reboot without it. The reference above suggests it should be there, so I am proposing that your grub.conf file was missing or incorrect because my results were similar:
'invalid magic number: 9090
Error 13: Invalid or unsupported executable format
Press any key to continue...'
So as of now I can reproduce the problem. I will be updating this as I discover what will solve it for my solution, post it with hope it fixes it for yours or others who share similar issues.
I noticed something odd, I was using a Combo USB hub and tried to reboot using the other kernel (2.6) and there were considerable failures which were squawking on the startup screen and it would not permit me to start. When I removed it I could not boot into the 3.10, but only into 2.6.
Ok, a quick find on grub.conf revealed a similar version to that shown on the reference link above in /etc. So I copied the grub.conf from /etc to /boot/grub and rebooted. But I too see similar results. The USB hub is off the system and will not be reattached, so there is something else here that needs review. I'm digging into the grub.conf file at this time...
(update) I see that there is a grub.conf file under /boot/efi/EFI/redhat. Oddly in the Centos 'bug archives' there appears to be a related resolved bug for Centos 7: bugs.centos.org/view.php?id=7242 (cannot post this as a link as my reputation is less than 10, my apologies)
Also, as this relates to magic number here are results for my type of files and magic numbers, but I have done this with vi and have some assumptions here about what I saw, so I am retrying this with the help of the other stackoverflow article which uses file-devel package LibMagic... here are the intermittent results.
File.x86_64 Magic number (if two bytes, just use first 2)
vmlinuz-2.6.32.504.el6.x86_64 /0x8c/0x8e/0x8e/0x8e
vmlinuz-3.10.56-11.el6.centos.alt.x86_64 /0x8c/0x8e/0x8e/0x8e
Note: A search of '9090' on centos.org using the provided search engine for words on the site yielded no response on 12/22/14: #wiki.centos.org/Search
There is no mention of installation problems with SELinux, even though I have set:
SELINUX=disabled
in the /etc/sysconfig/selinux file and
yum uninstall xen
yum install xen
/usr/bin/grub-bootxen.sh
No results, and no new grub file in any of the three locations listed above. /etc /boot or /boot/efi/EFI/redhat.
Comparison of the grub.conf files with other sources, show that it is reasonable. Same for the grub-bootxen.sh file based on what I could decipher from bash.
Changing the timeout in grub.conf (all I found) to 15 and removing the hiddenmenu command by #hiddenmenu, did not eliminate the '9090' error. Using: wiki.xen.org/wiki/RHEL6_Xen4_Tutorial which shows the 'kernel' modifier instead of the 'module' and changing the 'module' in front of the .img file to initrd, did not change the results.
OK. Reload.
1) reinstall minmum Centos
2) disable SE Linux
3) reboot
4) correct ifcfg-eth0 (remove NM and allow boot on startup) and service network restart
5) yum import centos-release-xen (accept import of GPG key)
6) yum install xen
7) investigate what occurs with "grub-install hd0" which produces '9090' error!
Ok, I would have to say that the question was not well defined. It is now well defined and can be posed as a question. I will convert this info and my trials to a reasonable question to see if anyone can assist with pointers...
I'm connected to my university's small Linux cluster via PuTTY and WinSCP, transferring files using the latter and compiling and running them with the former. My work so far has been performed in the university's labs, but today I have been doing some work at home that generated an interesting warning.
I uploaded an entire folder of stuff and, upon running the make command, I get this as the last line of output:
make: warning: Clock skew detected. Your build may be incomplete.
The resulting binary works correctly, and there doesn't seem to be any other unexpected errors in the build process.
I seem to be able to trigger the error by building after uploading some new / replacement files (I edit everything locally then upload the new version), so I'm wondering if it's something just as simple as mismatched file modification times? Or something more concerning?
So, should I be worried? How do I fix/prevent this?
That message is usually an indication that some of your files have modification times later than the current system time. Since make decides which files to compile when performing an incremental build by checking if a source files has been modified more recently than its object file, this situation can cause unnecessary files to be built, or worse, necessary files to not be built.
However, if you are building from scratch (not doing an incremental build) you can likely ignore this warning without consequence.
Typically this occurs when building in a NFS mounted directory, and the clocks on the client and the NFS server are out of sync.
The solution is to run an NTP client on both the NFS server and all clients.
Install the Network Time Protocol
This also happened to me when running make on a Samba SMB CIFS share on a server.
A durable solution consists in installing the ntp daemon on both the server and the client.
(Please, note that this problem is not solved by running ntpdate. This would resolve the time difference only temporarily, but not in the future.)
For Ubuntu and Debian-derived systems, simply type the following line at the command line:
$ sudo apt install ntp
Moreover, one will still need to issue the command touch * once (and only once) in the affected directory to correct the file modification times once and for all.
$ touch *
For more information about the differences between ntp and ntpdate, please refer to:
Time Synchronisation with NTP
How To Set Up Time Synchronization on Ubuntu 16.04
Simple solution:
# touch filename
will do all OK.
For more info:
http://embeddedbuzz.blogspot.in/2012/03/make-warning-clock-skew-detected-your.html
The other answers here do a good job of explaining the issue, so I won't repeat that here. But there is one solution that can resolve it that isn't listed yet: simply run make clean, then rerun make.
Having make remove any already compiled files will prevent make from having any files to compare the timestamps of, resolving the warning.
type in the terminal and it will solve the issue:
find . -type f | xargs -n 5 touch
make clean
clean
According to user m9dhatter on LinuxQuestions.org:
"make" uses the time stamp of the file to determine if the file
it is trying to compile is old or new. if your clock is bonked, it may have problems compiling.
if you try to modify files at another machine with a clock time ahead by a few minutes and transfer them to your machine and then try to compile it may cough up a warning that says the file was modified from the future. clock may be skewed or something to that effect ( cant really remember ). you could just ls to the offending file and do this:
#touch <filename of offending file>
I have had this in the past - due to the clocks being out on the machines. Consider setting up NTP so that all machines have the same time.
This is usually simply due to mismatching times between your host and client machines. You can try to synchronize the times on your machines using ntp.
The solution is to run an NTP client , just run the command as below
#ntpdate 172.16.12.100
172.16.12.100 is the ntp server
Replace the watch battery in your computer. I have seen this error message when the coin looking battery on the motherboard was in need of replacement.
(Just in case anyone lands here)
If you have sudo rights one option is to synchronize the system time
sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
Make checks if the result of the compilation, e.g. somefile.o, is older than the source, e.g. somefile.c. The warning above means that something about the timestaps of the files is strange. Probably the system clocks of the University server differs from your clock and you e.g. push at 1 pm a file with modification date 2 pm. You can see the time at the console by typing date.
This happened to me. It's because I ran make -j 4 and some jobs finished out of order. This warning should be expected when using the -j option.