I have built, installed my custom kernel. I need to prove that the new kernel is built and running. I have tried exploring /var/log/ for the log messages. I searched Xorg.log and dmesg.log and boot.log files for getting information about my newly built kernel, but I am unable to find the logs for the same. Can anyone let me know how and where I can find the logs for my new kernel. I am using ubuntu.
Thanks.
#user2559758 you need to go into General Settings tab and select the older kernel version as the default Kernel. (there is a drop down menu, choose your old kernel as default kernel). Now save your changes (top left corner). exit grub loader. reboot. Once the reboot happens, cp /var/log/dmseg ~/oldlog. Again run grub-customizer switch to General Settings (2nd tab) choose new kernel version, save, reboot. Now you can copy cp /var/log/dmesg ~/newlog . Now do diff oldlog newlog
Let me know if you have issues. If the answer is still unclear, please send the screenshot of General Settings tab. Also give the name of new and old kernel version names and I will be able to assist you better.
You can get the kernel version by running uname -a. If you built your new kernel with a unique version name (I don't recall off hand where the setting is in the kernel configuration), it'll be obvious which kernel you're running.
Related
I'm on a Yocto Linux distribution and I need to set the sysctl tunable kernel.panic_on_rcu_stall to 1. The problem is when I list the elements inside /proc/sys/kernel I have no panic_on_rcu_stall and if I try to set the option anyway I get the folowing error:
# sysctl -w kernel.panic_on_rcu_stall=1
sysctl: error: 'kernel.panic_on_rcu_stall' is an unknown key
I know that the key exist, we can see it on the Linux Kernel documentation, but it also specify that
Currently, these files might (depending on your configuration) show up in /proc/sys/kernel:
And this is all about, what the documentation means by your configuration and how to change it.
I'm using the 4.4.38+linaro Linux kernel.
Thanks in advance.
Thanks for your comments, Tsyvarev was right, after applying this patch to my kernel recipe in my Yocto project, the option kernel.panic_on_rcu_stall appeared in /proc/sys/kernel.
In the past, Ghostscript used to incorporate these Apple Imagewriter devices: iwhi, iwlo, and iwlq. The version I had been using is gs 8.7 which is not 64-bit compliant. macOS Catalina cannot use it or any other 32 bit code, so printing to those devices fails.
More recent versions including the most recent Ghostscript 9.27 omit those devices. I don't know when they were omitted or why but it seems to be a while ago. Worse, I don't know how they get incorporated in Ghostscript. Other than building gs from its source code, which I have done, I don't know where to begin. The new Ghostscript 9.27 itself works fine in macOS Catalina. It includes many "built-in" devices but the ImageWriter devices I need are absent.
The drivers and Ghostscript were originally obtained from the Linux Foundation's Open Printing website: https://openprinting.org/printer/Apple/Apple-ImageWriter_II, but they were bundled and distributed in a package form that recent macOS versions cannot handle. That web page also indicates the drivers are "Type: Ghostscript built-in" which it no longer is in recent versions.
Here is gs -h using the installed 32 bit version:
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
-dNOPAUSE no pause after page | -q `quiet', fewer messages
-g<width>x<height> page size in pixels | -r<res> pixels/inch resolution
-sDEVICE=<devname> select device | -dBATCH exit after last file
-sOutputFile=<file> select output file: - for stdout, |command for pipe,
embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PostScriptLevel3 PDF
Default output device: bbox
Available devices:
alc1900 <snip> inferno iwhi iwlo iwlq jetp3852 jj100 <many other devices> <snip>
Search path:
. : %rom%Resource/Init/ : %rom%lib/ :
/usr/local/share/ghostscript/8.71/Resource/Init :
/usr/local/share/ghostscript/8.71/lib :
/usr/local/share/ghostscript/8.71/Resource/Font :
/usr/local/share/ghostscript/fonts :
/usr/local/share/fonts/default/ghostscript :
/usr/local/share/fonts/default/Type1 :
/usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
/usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType :
/usr/share/cups/fonts
Initialization files are compiled into the executable.
For more information, see /usr/local/share/ghostscript/8.71/doc/Use.htm.
Please report bugs to bugs.ghostscript.com.
iMac4:ghostscript-9.27 john$
The obvious sticking point is right there in front of me: "Initialization files are compiled into the executable." I know that, but what initialization files (if any) need to be included or modified to ensure their incorporation in the build? I have printer PPDs for the ImageWriter. They're just text files, and I think they would be required. Should they? How?
The only way I have attempted to build gs from source is to use ./configure followed by make That begins a long compilation process that takes a few minutes, and results in an executable gs that works fine in Catalina. The problem is it does not include the drivers I want. Attempting to print to that printer results in it printing "Unknown device: iwhi" in straight ASCII text (not bitmapped).
By now it ought to be painfully obvious I'm well over my head and don't know where to turn. Can anyone point me in the right direction from here?
Some background can be found here: Apple ImageWriter printer installation in… - Apple Community
. I wrote it. Some of its links are dead. If a picture doesn't load and you want to see it, click on it (it's a site problem).
A recent Discussion describing this dilemma is here: 32-bit ghostscript, required for ImageWriter and other printers using CUPS
The devices quoted were removed in this commit If you need them then you should be able to :
Clone our git repository, help on this is here
git checkout a87e380acd5e326f7d4e4380348bac393fac3058
copy the ghostpdl/devices/gdevadmp.c file somewhere convenient
git checkout master (or if you want a tagged release rather than the bleeding-edge code, git checkout ghostpdl-9.27 for example)
copy the saved file back to ghostpdl/devices/gdevadmp.c
Undo the changes in contrib.mak, configure.ac and unix-gcc.mak
(using the link to the gitweb you can see the diffs, they are not
extensive)
In the ghostpdl directory: ./autogen.sh then make
That all assumes you have a working C compiler (gcc, make etc) and development environment, but you say you've already built GS from source so that should be fine. The end result should be a woking Ghostscript with the additional device built in.
This:
Initialization files are compiled into the executable.
refers to the PostScript initialisation files, and won't help you with devices which are written in C and have to be compiled. While the line above is technically correct, you can use the -I switch to override the ROM file syatem (which is what that refers to) and have the initialisation files stored on disk instead.
PPD files aren't going to help you with Ghostscript, these are PostScript Printer Description files and they are used by applications which generate PostScript to customise the PostScript program for the specific printer. These are (I think) used by CUPS, but not by Ghostscript.
I think THIS is the commit to remove gdevadmp.
I think this was removed in a flurry of activity removing stuff referred to as "moribund" MacOS and classic Mac stuff, and I think this specific removal was unwarranted and unwise, as these drivers are still in use today Using foomatic-rip:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=a87e380acd5e326f7d4e4380348bac393fac3058
I am another Mac User and ImageWriter and ImageWriterLQ owner, I do not speak for Artifex.
at version 9.05, the file gdevadmp containing appledmp, iwhi, and iwlo, and iwlq was MOVED into the 'devices' folder. It survived there until version 9.20.
After version 9.20 it was removed in an operation that included only gdevadmp and its supporting files. The note does not say WHY it was removed.
So a 64-bit build of ghostscript 9.20 has some potential.
The files available at:
https://wiki.linuxfoundation.org/openprinting/macosx/foomatic#ghostscript_for_mac_os_x_103x_panther_-_mac_os_x_109x_mavericks
are still good, but gs and the filters need to be moved to a directory that remains accessible after the lockdown of sandboxing (about Mavericks) Suggested directory is noted in the apple support community discussion you posted earlier.
Links on the Ghostscript web site say that THIS (StackOverflow) is the official forum for discussing issues related to Ghostscript.
If that is not appropriate, what do Artifex and Ghostscript developers suggest is the "official" forum for Ghostscript issues?
I stumbled across this thread while working on a shelter-in-place project to resurrect my ImageWriter II by building Ghostscript and cups-filters for Catalina. My solution isn’t quite there yet; I can get 75% of the CUPS printer test page printed before silently crashing.
The solution for defeating sandboxing is to compile Ghostscript with dynamic linking disabled. Otherwise, even if you move the gs executable into a sandbox blessed location, the gs process will get killed as soon as it tries to link in the drivers. From my notes:
Download Ghostscript 9.20, the last gs with the Apple dot matrix drivers: https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/tag/gs920
Build Ghostscript with the drivers statically linked in (otherwise sandboxing gets you): ./configure --disable-dbus --disable-dynamic --disable-gtk --with-drivers=APPLE,PS --prefix=/usr/local/ghostscript-9.20
I have not yet tried to forward-port the iwhi drivers and such into the Ghostscript; that’s my next task, in the hope that it fixes the silent crash.
I need to study something and change in the ipc_namespace.h but I cannot find it. Can someone please specify the correct path to it and also let me know if I can some thing in that file and restart my OS will the changes take place?
For me: /usr/src/linux-headers-3.5.0-27-generic/include/linux/ipc_namespace.h and for you possibly depends on you kernel version.
Use: apt-file search ipc_namespace.h to locate it.
About changing it, no a simple restart will not do the trick, you will need to recompile highly possibly your kernel for the changes to happen. (And I'm not an expert in this area :( )
For no reason that I can see, I can no longer run a TortoiseSVN Update on a development directory on my portable Windows XP Professional SP3 machine, getting the error:
Previous operation has not finished; run 'cleanup' if it was interrupted
Please execute the 'Cleanup' command.
If I try running cleanup, I get another error,
cannot process the following paths: cannot move $ROOT_DIR/.svn/tmp/tmp-... to $ROOT_DIR/path/where/thing/should/go: no such file or directory
I have verified that both files exist, and actually from CMD.EXE prompt I am able to issue a MOVE with those two filenames and have it work correctly. It's no use because next time SVN tries to repeat the operation itself after creating a different tmp file name, and while CMD succeeded, SVN fails.
UPDATE: the path lengths are in both cases well below PATH_MAX, target file system is NTFS, and permissions are OK. Maybe I'll now try with FileMon to see whatever TortoiseSVN is really up to.
I tried downgrading TortoiseSVN but to no avail. Other repositories work OK between the same machines.
TortoiseSVN 1.7.9, Build 23248 - 32 Bit , 2012/08/30 18:25:37
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7
Both server (OpenSuSE Linux 12.2) and client now run the latest version of SVN.
On Windows, I also cannot seem to get any more informative logs or information (I'm not very skilled with TortoiseSVN, I have always used the Linux command line version).
I might delete the local copy and run a checkout, but it's about 2 GB of data, and I'm on a slow connection, so it is really more of a "fly physically to server location and hook a copper Ethernet to the local network there" alternative. I'm reserving that as a sort of last ditch, nuclear option; I'd really rather understand what the problem is, for I fear it might happen again.
UPDATE
I've tried to delete remotely the subdirectory involved, committing the deletion on the server; deleting the subdirectory locally, and emptying the .svn/tmp subdirectory where I found sixteen tmp files, all copies of the one PNG causing problems.
I am still not able to perform any SVN subcommand, getting "Run cleanup!" error; on cleanup; I get a failed attempt to copy a tmpfile to the never-sufficiently-damned .PNG file, which no longer exists anywhere, into a directory that no longer exists anywhere.
I tried recreating the directory locally (but not the file!), no changes.
With FileMon, I traced the source PNG to 8e4c2389cf9d85c8b8ee54d49ea053c752a38187.svn-base in .svn/pristine subdirectory, tried removing it and got SVN complaining. I tried copying it to its intended destination (so that the file-as-it-should-be and the file-as-it-is are identical), no joy.
UPDATE
Well, this is weird. I decided to track everything that TortoiseSVN is doing using FileMon. I could see it checking the wc.db and search the item, checking for it in .svn/pristine (and finding it), copying it (unnecessarily if you ask me...) in .svn/tmp, and finally checking $DESTINATION_FILE (with correct case) using Windows Open() API. And getting PATH NOT FOUND. Yet the file is there, I can see it (and the name is less than 8.3 characters). And why PATH not found and not FILE not found?
Okay, it all boiled down to a directory that had been created remotely with a name ending with space. The file in itself was OK; the directory where it stood was not.
When updating, apparently, the directory got created but the name was shortened by Windows to exclude the final space.
To add to the difficulty of diagnosing, while TortoiseSVN did tell me what the problem was, it did so in the dialog box where the Arial font made the space in \path\to\your \file not clearly recognizable (it was, once I knew where to look, and compared that slash with the others. This one stood a little farther from the letter at its left).
Lesson learned: check really carefully the dialog file name, character by character (note to self: find a way of having it in Courier New if at all possible).
You may have two files in the repository that differ only in case. That's a problem on Windows. See this FAQ for details.
In my boot options of my installed CentOS on VBox, I have the followings that really mess me up to figure out how to eliminate those that doesn't work anymore, e.g the first one which is reported as unavailability of kernel root to boot. I can only choose the last one to boot the system.
> CentOS(2.6.32-200.17.1.e16.x86_64)
> CentOS(2.6.32-200.17.1.e16.x86_64.debug)
> CentOS(2.6.32-200.4.2.e16.x86_64.debug)
> CentOS(2.6.32-200.4.2.e16.x86_64)
> CentOS(2.6.32-200.4.1.e16.x86_64)
> CentOS(2.6.32-200.e16.x86_64)
Where are these stored once I boot the system with the last option ? What if I would like to delete (completely) one of them ? I don't know what the xxx.debug's are there for ?
Thank you for any help
On most distros today the boot manager is GRUB. The configuration of boot menu is usually stored in /boot/grub in a file called menu.lst or grub.cfg depending on GRUB version and distro. In that file, you can comment out sets of lines corresponding to the OS you don't want in the menu - syntax should be pretty intuitive.
On some distros the file is generated by a set of scripts, in this case a comment at the top say you shouldn't edit that file directly. For example in Debian, the scripts which generate the configuration reside in /etc/grub.d/ and they do all sorts of auto-probing for available OS's. In this case one needs to either modify the script or to remove the OS images which are automatically appended to the menu. The exact way to do this cleanly may vary depending on your setup - perhaps some of these boot images can be removed using a package manager which would be more elegant than just removing files manually.
Either way, be careful, since removing the wrong file related to booting may make it impossible to boot your OS or even to start GRUB at all if you're extremely unlucky.