The 2GB threshold comes from the fact, that the machine I am working on only supports SD (not SDHC) which are max 2GB big.
So far I have managed to compile the kernel with my adjusted kernel config and applied RT-Patch. But I am stuck trying to get this kernel into my bootable USB. The tutorials I found create Live USBs bigger than 2GB. (this for example breaks at tar -xpf ~/Download/portage-latest.tar.xz) And the minimal Gentoo x86 img does not contain the kernel bzImage or any lib/modules directory:
2048 2,0K drwxr-xr-x 3 root root 2,0K Sep 29 08:08 gentoo.efimg.mountPoint
1873 179M -rw-r--r-- 1 root root 179M Sep 29 08:08 image.squashfs
1920 4,0K drwxr-xr-x 2 root root 4,0K Sep 29 08:06 isolinux
1881 0 -rw-r--r-- 1 root root 0 Sep 29 08:06 livecd
1885 7,5K -rw-r--r-- 1 root root 7,1K Sep 29 08:06 README.txt
I have gotten so far that I mounted image.squashfs and found /mtn/modules but I still can't locate the kernel bzImage.
Can someone point me to a good tutorial or provide one?
Related
I am completely new to Linux and want to write a website in Yekyll. therefore I have to install Ruby first. Unfortunately this does not work properly. As far as I can see, I do not have the correct rights for Ruby. but I already set the rights to rwx. So I cannot see what else I can do. Can anybody help me please?
Here is what I did and received:
raphael#raphael-ThinkCentre-M58:~$ gem install jekyll bundler
ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions for the /var/lib/gems/2.5.0 directory.
raphael#raphael-ThinkCentre-M58:~$
raphael#raphael-ThinkCentre-M58:~$ sudo ls -al /var/lib/gems/2.5.0
[sudo] password for raphael:
total 32
drwxr-xr-x 8 root root 4096 Nov 17 10:08 .
drwxr-xr-x 3 root root 4096 Nov 17 09:51 ..
drwxr-xr-x 2 root root 4096 Nov 17 10:08 build_info
drwxr-xr-x 2 root root 4096 Nov 17 10:25 cache
drwxr-xr-x 3 root root 4096 Nov 17 10:08 doc
drwxr-xr-x 3 root root 4096 Nov 17 10:25 extensions
drwxr-xr-x 7 root root 4096 Nov 17 14:48 gems
drwxr-xr-x 2 root root 4096 Nov 17 10:25 specifications
This is much to small to give it to a professional, but never the less it stops my working since two days. :(
Any ideas? Thanks!
I've run through the tutorial here: https://appimage-builder.readthedocs.io/en/latest/intro/tutorial.html#
Which resulted in a runable Qt AppImage Template-latest-x86_64.AppImage file (no docker tests were run).
Initially, the AppImage works as expected. Double-clicking the AppImage from the GUI or running it via the console results in the tutorial application running.
However, two scenarios will result in the AppImage file no longer working:
If the machine which built the AppImage is rebooted, the same AppImage will no longer run.
If the AppImage is transferred to a different machine it will no longer run. The machine has the same version of the OS that the AppImage was built on.
Both scenarios have the same behavior. The application will appear as if it contains no executable code and immediately exit. Normally the application has a GUI interface. No error message is displayed.
Running from console:
tb#dt:~/appimage_tutorial/qt-appimage-template$ ll
total 176860
drwxr-xr-x 8 tb tb 4096 Nov 23 14:25 ./
drwxr-xr-x 3 tb tb 4096 Nov 23 14:18 ../
drwxr-xr-x 6 tb tb 4096 Nov 23 14:25 AppDir/
drwxr-xr-x 4 tb tb 4096 Nov 23 14:25 appimage-builder-cache/
-rw-r--r-- 1 tb tb 3430 Nov 22 22:35 AppImageBuilder.yml
-rw-r--r-- 1 tb tb 13981 Nov 23 14:18 CMakeCache.txt
drwxr-xr-x 4 tb tb 4096 Nov 23 14:18 CMakeFiles/
-rw-r--r-- 1 tb tb 1808 Nov 23 14:18 cmake_install.cmake
-rw-r--r-- 1 tb tb 439 Nov 23 14:18 CMakeLists.txt
-rw-r--r-- 1 tb tb 498 Nov 23 14:18 conanfile.txt
drwxr-xr-x 8 tb tb 4096 Nov 23 14:18 .git/
-rw-r--r-- 1 tb tb 19 Nov 23 14:18 .gitignore
-rw-r--r-- 1 tb tb 450 Nov 23 14:18 .gitlab-ci.yml
-rw-r--r-- 1 tb tb 159 Nov 23 14:18 install_manifest.txt
-rw-r--r-- 1 tb tb 6948 Nov 23 14:18 Makefile
-rwxr-xr-x 1 tb tb 181010472 Nov 23 14:25 'Qt AppImage Template-latest-x86_64.AppImage'*
-rw-r--r-- 1 tb tb 67 Nov 23 14:18 README.md
drwxr-xr-x 3 tb tb 4096 Nov 23 14:18 res/
drwxr-xr-x 4 tb tb 4096 Nov 23 14:18 src/
tb#dt:~/appimage_tutorial/qt-appimage-template$ ./'Qt AppImage Template-latest-x86_64.AppImage'
tb#dt:~/appimage_tutorial/qt-appimage-template$
(nothing happens)
gdb:
(gdb) run
Starting program: /home/tb/appimage_tutorial/qt-appimage-template/Qt AppImage Template-latest-x86_64.AppImage
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
process 2651 is executing new program: /tmp/.mount_Qt AppVj8Ud9/AppRun
[Inferior 1 (process 2651) exited with code 01]
(gdb)
The AppImage was built from the ~/appimage_tutorial/qt-appimage-template directory using: appimage-builder --skip-test
Here is the last part of the output from when the AppImage was being built:
INFO:root:Writing bundle info to: .bundle.yml
INFO:root:Downloading runtime: https://github.com/AppImage/AppImageKit/releases/download/continuous/runtime-x86_64
INFO:root:Generating AppImage from ./AppDir
INFO:appimagetool:appimagetool --runtime-file appimage-builder-cache/runtime-x86_64 ./AppDir /home/tb/appimage_tutorial/qt-appimage-template/Qt AppImage Template-latest-x86_64.AppImage
INFO:appimagetool:Parallel mksquashfs: Using 4 processors
INFO:appimagetool:Creating 4.0 filesystem on /home/tb/appimage_tutorial/qt-appimage-template/Qt AppImage Template-latest-x86_64.AppImage, block size 131072.
INFO:appimagetool:[============- ][===========================================================\] 11826/11826 100%
INFO:appimagetool:
INFO:appimagetool:Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
INFO:appimagetool:compressed data, compressed metadata, compressed fragments,
INFO:appimagetool:compressed xattrs, compressed ids
INFO:appimagetool:duplicates are removed
INFO:appimagetool:Filesystem size 176580.52 Kbytes (172.44 Mbytes)
INFO:appimagetool:35.82% of uncompressed filesystem size (492966.84 Kbytes)
INFO:appimagetool:Inode table size 142021 bytes (138.69 Kbytes)
INFO:appimagetool:23.51% of uncompressed inode table size (604061 bytes)
INFO:appimagetool:Directory table size 152721 bytes (149.14 Kbytes)
INFO:appimagetool:33.80% of uncompressed directory table size (451834 bytes)
INFO:appimagetool:Number of duplicate files found 1031
INFO:appimagetool:Number of inodes 15794
INFO:appimagetool:Number of files 8380
INFO:appimagetool:Number of fragments 355
INFO:appimagetool:Number of symbolic links 6432
INFO:appimagetool:Number of device nodes 0
INFO:appimagetool:Number of fifo nodes 0
INFO:appimagetool:Number of socket nodes 0
INFO:appimagetool:Number of directories 982
INFO:appimagetool:Number of ids (unique uids + gids) 1
INFO:appimagetool:Number of uids 1
INFO:appimagetool:root (0)
INFO:appimagetool:Number of gids 1
INFO:appimagetool:root (0)
INFO:appimagetool:/home/tb/appimage_tutorial/qt-appimage-template/AppDir should be packaged as /home/tb/appimage_tutorial/qt-appimage-template/Qt AppImage Template-latest-x86_64.AppImage
WARNING:appimagetool:appimagetool, continuous build (commit aaef827), build 2143 built on 2020-11-22 12:53:26 UTC
WARNING:appimagetool:Using architecture x86_64
WARNING:appimagetool:Deleting pre-existing .DirIcon
WARNING:appimagetool:Creating .DirIcon symlink based on information from desktop file
WARNING:appimagetool:WARNING: AppStream upstream metadata is missing, please consider creating it
WARNING:appimagetool:in usr/share/metainfo/QtQuickControls2Application.appdata.xml
WARNING:appimagetool:Please see https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
WARNING:appimagetool:for more information or use the generator at http://output.jsbin.com/qoqukof.
WARNING:appimagetool:Generating squashfs...
WARNING:appimagetool:Embedding ELF...
WARNING:appimagetool:Marking the AppImage as executable...
WARNING:appimagetool:Embedding MD5 digest
WARNING:appimagetool:Success
WARNING:appimagetool:
WARNING:appimagetool:Please consider submitting your AppImage to AppImageHub, the crowd-sourced
WARNING:appimagetool:central directory of available AppImages, by opening a pull request
WARNING:appimagetool:at https://github.com/AppImage/appimage.github.io
INFO:root:AppImage created successfully
I suspect you did not install an appropriate AppRun in the AppDir directory.
But the process fails without error message.
I suggest you run the AppImage with strace to see more.
I maintain some legacy code that runs on RH Linux that sends inserts over the network to a client's Sybase. We were using Sybase 12.5 libraries and have just migrated to use Sybase 15.0 client libraries.
My application logs the time at which it sends the insert over the network and also the time it get the acknowledgment back from the target Sybase. When using 12.5 libraries the time was ~5 ms, now with the 15.5 libraries it's roughly 50 ms.
The only change I've made on the application side is to specify the location of the interfaces file on the command line. Previously the file was located in the default location - the location of the Sybase installation. Now it's located where the application is deployed, hence the need to specify the location explicitly.
Would anyone have any idea what is causing the dramatic change in speed, or have hints on where I could look or ideas on how to trace the root cause?
Please forgive the lack of technical details. I'm not a DB admin but a developer using a compiled library to connect to Sybase and don't have access to the nitty-gritty internals. That being said, I'm using the same internal library in both cases, it's only the Sybase librairies that are different.
My Sybase 12.5 and 15 installations look like this:
$ ls -l /opt/sybase/
total 48
-rw-r--r-- 1 root root 555 Jul 2 2019 ASE150.csh
-rw-r--r-- 1 root root 259 Jul 2 2019 ASE150.env
-rw-r--r-- 1 root root 388 Jul 2 2019 ASE150.sh
drwxr-xr-x 10 root root 4096 Feb 2 2017 OCS-15_0
-rw-r--r-- 1 root root 555 Jul 2 2019 SYBASE.csh
-rw-r--r-- 1 root root 259 Jul 2 2019 SYBASE.env
-rw-r--r-- 1 root root 388 Jul 2 2019 SYBASE.sh
drwxr-xr-x 58 root root 4096 Jul 2 2019 charsets
drwxr-xr-x 3 root root 4096 Jul 2 2019 collate
drwxr-xr-x 2 root root 4096 Nov 23 20:55 config
-rw-r--r-- 1 root root 1239 Jul 2 2019 interfaces
drwxr-xr-x 5 root root 4096 Nov 23 20:55 locales
$ ls -l ~/12_5/sybase/
total 28
drwxrwxr-x 4 oadc oadc 4096 Nov 29 2017 OCS-12_5
drwxrwxr-x 58 oadc oadc 4096 Nov 29 2017 charsets
drwxrwxr-x 2 oadc oadc 4096 Mar 16 09:45 config
drwxrwxr-x 2 oadc oadc 4096 Mar 16 09:45 include
-r-xr-xr-x 1 oadc oadc 1184 Mar 16 09:45 interfaces
drwxrwxr-x 2 oadc oadc 4096 Mar 16 09:45 lib
drwxrwxr-x 5 oadc oadc 4096 Mar 16 09:45 locales
EDIT
After some more digging it looks like the libraries under OCS-12-5 are not actually for 12_5 but for 15_5!
$ strings sybase/OCS-12_5lib/libsybct*.a | grep "Sybase Client-Library"
Sybase Client-Library/15.5/P/DRV.15.5.0/Linux x86_64/Linux 2.6.9-55.ELsmp x86_64/BUILD1550-003/64bit/OPT/Mon Oct 5 23:16:48 2009
Sybase Client-Library/15.5/P/DRV.15.5.0/Linux x86_64/Linux 2.6.9-55.ELsmp x86_64 Native Threads/BUILD1550-003/64bit/OPT/Tue Oct 6 00:06:57 2009
Which means that my assumption that 12.5 was faster than 15.0 is wrong. What is actually happening is that 15.5 is faster than 15.0. Which makes more sense.
I'm not going to go hunt down the idiot that submitted these files into a directory labelled OCS-12-5 ...
After some more digging it looks like the libraries under OCS-12-5 are not actually for 12_5 but for 15_5!
$ strings sybase/OCS-12_5lib/libsybct*.a | grep "Sybase Client-Library" Sybase Client-Library/15.5/P/DRV.15.5.0/Linux x86_64/Linux 2.6.9-55.ELsmp x86_64/BUILD1550-003/64bit/OPT/Mon Oct 5 23:16:48 2009 Sybase Client-Library/15.5/P/DRV.15.5.0/Linux x86_64/Linux 2.6.9-55.ELsmp x86_64 Native Threads/BUILD1550-003/64bit/OPT/Tue Oct 6 00:06:57 2009
Which means that my assumption that 12.5 was faster than 15.0 is wrong. What is actually happening is that 15.5 is faster than 15.0. Which makes more sense.
I've updated the question with this new information.
I've been having some issues lately with my virtualbox. I tried reinstalling it but it won't help.
I don't get why my VB suddenly stopped working and won't start.
I tried looking if it has anything to do with permissions but I am not an expert in reading the following: Is it problem with permission ?
drwxr-xr-x# 30 root wheel 960 Oct 15 09:19 /
drwxr-xr-x+ 60 milicamiletic admin 1920 Oct 15 10:01 /Applications
0: group:everyone deny delete
drwxr-xr-x 3 root admin 96 Oct 15 10:01 /Applications/VirtualBox.app
-rw-r--r-- 1 root admin 5529952 Aug 14 14:04 /Applications/VirtualBox.app/Contents/MacOS/VBoxRT.dylib
drwxr-xr-x 6 root wheel 192 Nov 13 2017 /private
drwxr-xr-x 118 root wheel 3776 Oct 15 09:36 /private/etc
-r--r----- 1 root wheel 1563 Dec 11 2016 /private/etc/sudoers
drwxrwxrwt 8 root wheel 256 Oct 15 10:01 /private/tmp
Usually applications are installed not as root but as the user. you seem to have installed VirtualBox as root.
Moreover, it seems you are missing the main executable file.
Try reinstalling virtualbox as yourself
What is the location of all .vbox files that are created in virtual box in a mac. And how can we delete it?
I mistakenly deleted virtualbox.app file from Applications and now I want to delete all the remains of all virtual box files.
I tried following things:
drwxr-xr-x# 3 user admin 102 Dec 19 19:57 vagrant
-rw-r--r-- 1 root wheel 1824496 Feb 21 17:17 com.vagrant.vagrant.bom
-rw-r--r-- 1 root wheel 240 Feb 21 17:17 com.vagrant.vagrant.plist
drwx------ 5 root wheel 170 Feb 21 16:59 ubuntu-cloudimg-precise-vagrant-amd64_1487725164672_27815
./private/var/root/VirtualBox VMs/ubuntu-cloudimg-precise-vagrant-amd64_1487725164672_27815:
-rw------- 1 root wheel 3036 Feb 21 16:59 ubuntu-cloudimg-precise-vagrant-amd64_1487725164672_27815.vbox
-rw------- 1 root wheel 3036 Feb 21 16:59 ubuntu-cloudimg-precise-vagrant-amd64_1487725164672_27815.vbox-prev
lrwxr-xr-x 1 root wheel 24 Feb 21 17:17 vagrant -> /opt/vagrant/bin/vagrant
But I could not find the location of .vbox files to manually delete them.
By default the .vbox files normally go into your users' home directory:
pwd
/Users/Astro58/VirtualBox VMs
total 264
drwx------# 6 lance staff 204 Feb 22 19:03 ./
drwxr-xr-x+ 88 lance staff 2992 Feb 22 16:11 ../
drwx------ 6 lance staff 204 Feb 22 19:50 Laravel_default_1487808229046_76286/
drwx------ 7 lance staff 238 Feb 20 12:53 legacy_default_1487457532080_39585/
You should be able to delete the "VirtualBox VMs" directory via the rm command or via the Mac Finder.