Jump to content

ab1jx

Members
  • Posts

    22
  • Joined

  • Last visited

Posts posted by ab1jx

  1. 21 hours ago, gregb49 said:

    Are there other graphical package managers? I'm also used to synaptic, but the 20 minute wait between searches is infuriating. apt-get install is fine if you know the exact name of the package.

    That problem was cured by not keeping the package info in compressed form as far as I'm concerned.  You have to change something in a config file then delete the lists and apt-get update again.  It's 10-20 times as fast now.

     

    If you have to live without Synaptic try apt search.

  2. I'm still plugging away at this.  Different monitor and location, Ayufan image instead of Armbian.  This comes up in 1920x1080 for a 5 year old 1366x768 monitor.  For text/console mode.  X I can get to a 1024x768 but it's narrow like it's using 1024 of 1366 pixels.

     

    So I've been digging into it.  Apparently DRI sets up a virtual framebuffer.  I mostly can't change the size with fbset, xrandr thinks I'm still in 1920x1080 mode.  lxrandr from LXDE partly works, that's where I got the 1024x768.  I downloaded Ayufan's kernel source last night to poke around in.  My current theory is that the video mode is set in the boot process by some argument to the kernel, I haven't found it yet.  The Mali docs I've looked at seem to suggest that the Mali just uses the framebuffer after Linux sets it up, it doesn't control the size.

     

    I asked the guy I know, he didn't really know but the armsoc driver works for him.  Not sure which version, and that's only X.    I set up a full xorg.conf last night complete with a couple modelines.  I'm mostly using the modesettting driver I think, armsoc keeps telling me "(EE) ERROR: Did not find any matching device section in configuration file".  But then:

    
    [ 34674.661] (II) No BusID or DriverName specified - opening /dev/dri/card0
    [ 34674.661] (II) Got BusID display-subsystem
    [ 34674.661] (II) Opened DRM
    [ 34674.661] (II)    DeviceName is [/dev/dri/card0]
    [ 34674.661] (II)    bus_id is [display-subsystem]
    [ 34674.661] (II)    DriverName is [rockchip]
    [ 34674.662] (II)    version is [1.0.0]
    [ 34674.662] (II) ARMSOC: Driver for ARM Mali compatible chipsets
    
    

  3. Is that in libmali somewhere?  That seems to be just higher level stuff like CL EGL GLES.  That's probably the wrong place to look, I've seen a link for downloads at pine64.org, don't have it handy.

     

    In /lib/firmware/edid I see what appear to be 29 binary dumps of EDID data with video modes in the filenames.  Is something comparing the live EDID with the files and setting the mode from the filename on a match?  I know EDID has been through several versions that aren't necessarily compatible with each other.  Raspberrypi.org doesn't publish source of their EDID parser due to copyright issues.  I tried writing one once.

     

    I know somebody on the debian-arm mailing list with a Rock64 who uses the mode I want, I guess I should ask him how he gets it.  He does build his own kernels, I forget why.

     

  4. I'm trying to use it with a TV that has HDMI input but it's 1360x766.  xrandr says it's running at 1920x1080.  It's very small, like keep a magnifying glass handy, and I don't have the bottom of the screen where LXDE puts the pager and buttons.

     

    I thought from my Raspberry Pi experience that I'd just change the mode in my config.txt https://www.raspberrypi.org/documentation/configuration/config-txt/video.md but apparently the Rock64 isn't that evolved.  Can I set an HDMI mode in my armbianEnv.txt?  Can it use CVT modes?  The standard 1360x768 mode isn't quite right.  I've been around this stuff since you had to work out an xfree86.conf file on paper and take timings into account but that was with CRT monitors where the resolution didn't have to exactly match LCD resolutions.  Where do I change it?

     

    I have a couple monitors that a Pi's EDID parser doesn't work right on either, which is OK as long as there's a way to set the mode manually.  FWIW this is an Axess TVD-1801 a couple years old.  The PDF I just grabbed says 1366x768, something else said 766 vertically.

  5. Well, I guess I'll have to rig up a serial console.  I've got a couple of those serial-USB adapters and I think both my old laptops have "real" serial ports.  Not sure about flexibility on baud rates, stop bits, etc.  Except this is probably 3 or 5 volts, not +/- 12, there are chips that are level converters. I think I've got a couple.  OK, "They’re 3V3 TTL"  https://www.raspberrypi.org/blog/pinout-for-gpio-connectors/ 

    Always seemed like you could take an old 40 pin hard drive cable and only strip the wires you needed, might as well do 5 volts and ground at the same time.  My Pis and Zeroes have normal bootup messages.  Like what dmesg shows or /var/log/messages, or journalctl.  klogctl maybe.

     

    But you mean if some essential file gets trashed or there's a kernel panic I'd have to have a serial connection hooked up or I'd miss it?  Or wait forever staring at a blank screen.  Jeez.  Something I've seen logs all the boot messages into a file that gets overwritten next boot.  Maybe one of the BSDs.

  6. Hmm, nodm.  I just grabbed a copy onto my arm64 Pi to look at.  Is it possible to boot to a real command line, see the normal bootup messages, watch for errors, etc.?  It's mostly too fast to read but on my Pis I can tell if the wifi is having trouble getting a lease, that sort of thing.  What I see on the Rock with Armbian is a black screen until there's a login prompt.  If something's broken it just stays black.  I can put the SD in a reader and try to look at logs on another machine but it's a guessing game.  I set my default target to the multi user target but that didn't actually accomplish much.

  7. 1 hour ago, Igor said:


    How do you define more Debian? What is missing, what is too much, what you can not do?

     

    BTW. I use Debian Stretch with Gnome3 on my Notebook, but my server runs Ubuntu Bionic with XFCE. Both with reasons.
     


    The same or similar situation is with most mainstream Linux distribution. You can grab "clean" Debian or whatever, but almost nothing will work as you already figured out. You literally jump back few years. Not worth to have supposable cleaner Debian with no support, which will changed only a little since it's a generic distro. 

     


    Raspbian is Debian Stretch based with possible Wheezy compatibility hacks. I don't use it. I never did and don't plan to.

     

    Armbian is as clean as possible Jessie, Stretch and Stallmanised Ubuntu Xenial and Bionic.

     

    I imagine that someday you'll be able to go to https://www.debian.org/distrib/netinst and download an installer that will work on any Arm machine.  It will contain something that probes the various boot scenarios, find one that works, try network methods until one works or it gives up with a message about what to do next.  That would be an install kernel, which would download a real one and enough of the OS so you could pick what you wanted to install.  Something that works like menuconfig would be good, with defaults if you don't want to bother selecting, then it would do the downloading.  Wouldn't need X to do that, and maybe it wouldn't know about the full 57k of stuff Synaptic can access. On next boot you'd have a full kernel with the programs you selected, X and/or Weston or something else.  I think the differences between Pi, Rock, Banana, etc. could be handled by loading modules.

     

    At my last job we used to set up Windows machines and maintain them for an office of 30 people.  We used Sysprep and Ghost, we could reload a machine in half an hour.  Everybody got everything installed, whether they knew how to use it or not.  People could log out, go somewhere else and log in for an afternoon, everything worked the same.  Workstations were expendable, everything got done with files on a server, which used a RAID, had nightly backups to tape, all that.  I'm pretty sure we never lost anything in the 9 years I was there.  Viruses, hardware failures, all just part of the job.

     

    Raspbian was Wheezy when I started, now it's Stretch.  I'm building a tablet with a Pi and the 7 inch touchscreen they sell.  No physical keyboard, so I wanted to autologin as root.  Took a couple days to find the PAM rule preventing that, it was new with Stretch.  Now whenever something doesn't work I first suspect PAM, Selinux, Apparmor, all of which are in use.  I've been curious lately about http://www.linuxfromscratch.org/ but again I doubt it works out of the box on a particular Arm machine.  With OpenBSD there was source for everything, patches used patch(1) to apply text changes and you recompiled.  Kernel, apps, X, everything.  You can study the source as working examples by grepping for something in there.  With Linux you can get source but somehow it's not the same.

  8. Good to know.  I'm coming at Armbian from the perspective that I'd rather be using straight Debian, but the Arm machines have some peculiar hardware which require specialized knowledge, kernels, drivers, etc.  I want it to be as much like normal Debian as possible, not keep stumbling over hidden "helpful" features.  For that matter I'd probably be running OpenBSD but by last account they're woefully far behind and don't even have HDMI working yet, you can't install without a serial console.  As far as I'm concerned everything not an Arm machine is a dinosaur.  I still have a couple 10+ year old i386/amd laptops but most of my efforts go into setting up my Arm machines (and using them).  I'd like to get back to the Gphoto program I'm working on and some SDR stuff, not keep messing with operating systems.  But until Arms are as mainstream as i386 only Armbian, Raspbian, etc. can deal with them.

     

    With a relatively stock Pi all I have to do is set /etc/hostname so it's unique.  It boots up, DHCP works because it needs NTP.  I can get on the internet from it, also I can boot one headless and connect to that hostname from another machine.  I grudgingly gave up static IPs once I realized that hostnames from DHCP get fed to DNS in my Android phone hotspot/AP.  That's not quite right in my Rock64 yet.  On a Pi, even under Stapleberg's amd64 Buster it seems to not matter that much whether I use my interfaces file or not.  Sometimes I forget to make one or copy one in, it still works.

  9. Minor tweak.  I don't have gethostname() (Actually I think that's a C function, not an executable.)  Anyway my Rock64 didn't show up my wifi network by name.

     

    In /etc/dhcp/dhclient.conf I changed:

    #send host-name = gethostname();
    send host-name = $HOSTNAME;

     

    Now it works.  And $HOSTNAME is just whatever's in /etc/hostname so you may need to change it if you've got 2 or more machines of the same kind.  I mostly lug around a cell phone and I can ftp or ssh to rock64 from anywhere in the house.

  10. 6 hours ago, Myy said:

    I don't know where to look up the source code of this function. Valgrind might help you find the culprit too, also, if it's a memory/caching/branch-prediction related issue.

     

    Well the source code is here : https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/tagfile.cc

    But I don't see what would cause that much of a slowdown at first. That said the code is far from being easily readable.

     

    Especially hard to read if you don't use C++.  It took a little Googliing to figure out that jump in C++ is like jmp in assembly or goto in C or Basic.  I thought it was the actual name of a function.  I never found it, grepping and searching in editors.  pkgTagFile seems to be a type, like maybe a pointer to a stuct.  My guess is that it spends 90% of its time there just because it's called thousands of times.

     

    Anyway the problem went away, Synaptic works fine now, perfectly usable.  Maybe some change got made that upgrades put into effect.  Maybe going through /etc/apt and killing any mention of compress in it, I basically used an arm64 Buster version as a reference.  The improvement wasn't immediate.  I also deleted the files in /var/cache/apt (not the archives) and let them get recreated.  Highly unlikely but I was also fiddling with some m4 macros trying to get something ancient (maybe Synaptic) to build.  A search in Synaptic now takes about 8 seconds.

     

    Maybe Synaptic has been around since before compression could be used in apt cache files.  So it sort of works but it doesn't store the uncompressed version anywhere.  So a search means uncompressing hundreds or thousands of times.  The newest verson of Synaptic I could find was from 2012.  I consider it an essential tool though.

     

    I haven't tried Valgrind on this machine but on my other arm64 machine it doesn't work.  Not all the instructions have been registered.  I got it to work on a Pi (in 32 bit mode) by building it from the latest stable source, not using the version in the debs.  Same Valgrind, same Pi, under arm64 Buster, it doesn't work.  The CPU in a Pi does a mode switch, almost like usb mode switches can change a device from being in mass storage mode to something else.  There's 1 line in config.txt that changes it, in lscpu the architecture switches to aarch64, then it runs different instructions.

    synabt.png

  11. Fun having the extra horsepower (over a Pi).  Only 1 crash today, I'd just copied about 1 GB off to a hard drive in a USB adapter.  I suppose I could live with apt search.  Gimp 2.8 and UFRaw 0.22.

    DSC_5586_ri_lev_cur_shp40_1200_wm.jpg

  12. OK, this is from sysprof, I couldn't get gprof to work on it.

    
    SELF CUMULATIVE FUNCTION [ 0.24%] [ 100.00%] [Everything] [ 0.00%] [ 91.73%] [pool] [ 0.07%] [ 91.49%] In file /usr/sbin/synaptic [ 0.00%] [ 90.67%] pkgRecords::Lookup(pkgCache::DescFileIterator const&) [ 0.00%] [ 90.65%] pkgTagFile::Jump(pkgTagSection&, unsigned long long) [ 0.00%] [ 0.02%] pkgTagFile::Step(pkgTagSection&) [ 0.01%] [ 0.01%] memchr [ 0.00%] [ 0.00%] pkgTagSection::Scan(char const*, unsigned long, bool) [ 0.00%] [ 0.00%] pkgTagHash(char const*, unsigned long) [ 0.00%] [ 0.00%] In file /usr/lib/aarch64-linux-gnu/libapt-pkg.so.5.0.1 [ 0.00%] [ 0.00%] memset [ 0.00%] [ 0.00%] pkgTagSection::TrimRecord(bool, char const*&) [ 0.00%] [ 0.00%] In file /usr/lib/aarch64-linux-gnu/libapt-pkg.so.5.0.1 [ 0.00%] [ 0.00%] FileFd::Seek(unsigned long long) [ 0.00%] [ 0.00%] pkgTagSection::Scan(char const*, unsigned long, bool) [ 0.00%] [ 0.00%] pkgTagSection::Trim() [ 0.00%] [ 0.00%] FileFd::Skip(unsigned long long) [ 0.00%] [ 0.00%] pkgTagHash(char const*, unsigned long) [ 0.00%] [ 0.00%] memchr [ 0.00%] [ 0.00%] pkgTagSection::TrimRecord(bool, char const*&) [ 0.00%] [ 0.00%] memset [ 0.00%] [ 0.35%] pkgPackageManager::GetArchives(pkgAcquire*, pkgSourceList*, pkgRecords*) [ 0.00%] [ 0.07%] gtk_main_iteration [ 0.00%] [ 0.07%] gtk_dialog_run [ 0.02%] [ 0.05%] In file /usr/lib/aarch64-linux-gnu/libapt-pkg.so.5.0.1 [ 0.00%] [ 0.04%] pkgPackageManager::OrderInstall() [ 0.00%] [ 0.03%] Configuration::FindI(char const*, int const&) const [ 0.00%] [ 0.02%] pkgRecords::Lookup(pkgCache::VerFileIterator const&) [ 0.00%] [ 0.01%] pkgSourceList::ReadMainList() [ 0.00%] [ 0.01%] std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append(char const*, unsigned long) [ 0.01%] [ 0.01%] strcmp [ 0.01%] [ 0.01%] pkgCache::VerIterator::Downloadable() const [ 0.00%] [ 0.01%] gtk_events_pending [ 0.01%] [ 0.01%] __strcasestr [ 0.01%] [ 0.01%] In file /lib/aarch64-linux-gnu/libc-2.24.so [ 0.01%] [ 0.01%] pkgCache::VerIterator::TranslatedDescription() const [ 0.00%] [ 0.00%] pkgDepCache::ActionGroup::release() [ 0.00%] [ 0.00%] pkgAcquire::Run(int) [ 0.00%] [ 0.00%] XSync [ 0.00%] [ 0.00%] gtk_builder_add_from_file [ 0.00%] [ 0.00%] In file /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.22 [ 0.00%] [ 0.00%] operator new(unsigned long) [ 0.00%] [ 0.00%] std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long) [ 0.00%] [ 0.00%] OpProgress::Progress(unsigned long long) [ 0.00%] [ 0.00%] gtk_tree_view_set_model [ 0.00%] [ 0.00%] gtk_widget_show [ 0.00%] [ 0.00%] OpProgress::CheckChange(float) [ 0.00%] [ 0.00%] strcpy [ 0.00%] [ 0.00%] __read [ 0.00%] [ 0.00%] strlen [ 0.00%] [ 0.00%] gtk_list_store_set [ 0.00%] [ 0.00%] memcpy [ 0.00%] [ 0.00%] debSystem::CreatePM(pkgDepCache*) const [ 0.00%] [ 0.00%] std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::find(char, unsigned long) const [ 0.00%] [ 0.00%] gtk_progress_bar_set_fraction [ 0.00%] [ 0.00%] Configuration::Lookup(char const*, bool const&) [ 0.00%] [ 0.00%] free [ 0.00%] [ 0.00%] gtk_widget_set_sensitive [ 0.00%] [ 0.00%] __nanosleep [ 0.00%] [ 0.00%] gtk_menu_popup [ 0.00%] [ 0.00%] bcmp [ 0.00%] [ 0.00%] gtk_label_set_text [ 0.00%] [ 0.00%] strncasecmp [ 0.00%] [ 0.00%] operator delete(void*) [ 0.00%] [ 0.00%] g_object_new [ 0.00%] [ 0.00%] g_object_run_dispose [ 0.00%] [ 0.00%] memchr [ 0.00%] [ 0.00%] gtk_tree_view_column_new_with_attributes [ 0.00%] [ 0.00%] gtk_message_dialog_new [ 0.00%] [ 0.00%] In file /usr/lib/aarch64-linux-gnu/libgtk-3.so.0.2200.11 [ 0.00%] [ 0.00%] gtk_list_store_insert [ 0.00%] [ 0.00%] pkgDPkgPM::~pkgDPkgPM() [ 0.00%] [ 0.00%] time [ 0.00%] [ 0.00%] gtk_text_view_add_child_at_anchor [ 0.00%] [ 0.00%] pkgDepCache::MarkInstall(pkgCache::PkgIterator const&, bool, unsigned long, bool, bool) [ 0.00%] [ 0.00%] APT::Configuration::getLanguages[abi:cxx11](bool const&, bool const&, char const**) [ 0.00%] [ 0.00%] gtk_widget_hide [ 0.00%] [ 0.00%] Configuration::FindB(char const*, bool const&) const [ 0.00%] [ 0.00%] forkpty [ 0.00%] [ 0.00%] pkgArchiveCleaner::Go(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, pkgCache&) [ 0.00%] [ 0.00%] gtk_text_buffer_set_text [ 0.00%] [ 0.00%] gtk_widget_realize [ 0.00%] [ 0.00%] pkgAcquireStatus::Pulse(pkgAcquire*) [ 0.00%] [ 0.00%] std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long) [ 0.00%] [ 0.00%] pkgTagFile::Jump(pkgTagSection&, unsigned long long) [ 0.00%] [ 0.00%] g_strsplit [ 0.00%] [ 0.00%] nanosleep [ 0.00%] [ 0.00%] std::ostream::flush() [ 0.00%] [ 0.00%] SizeToStr[abi:cxx11](double) [ 0.00%] [ 0.00%] std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long) [ 0.00%] [ 0.00%] nl_langinfo_l [ 0.00%] [ 0.00%] g_object_thaw_notify [ 0.00%] [ 0.00%] In file /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.5000.3 [ 0.00%] [ 0.00%] gtk_widget_grab_focus [ 0.00%] [ 0.00%] g_type_check_instance_cast [ 0.00%] [ 0.00%] TimeToStr[abi:cxx11](unsigned long) [ 0.00%] [ 0.00%] gtk_label_set_markup [ 0.00%] [ 0.00%] nl_langinfo [ 0.00%] [ 0.00%] pkgTagSection::FindS[abi:cxx11](char const*) const [ 0.00%] [ 0.00%] - - kernel - - [ 0.00%] [ 0.00%] g_signal_connect_data [ 0.00%] [ 0.00%] g_signal_emit [ 0.00%] [ 0.00%] gtk_text_buffer_create_tag [ 0.00%] [ 0.00%] g_sequence_get_length [ 0.00%] [ 0.00%] gtk_list_store_new [ 0.00%] [ 0.00%] gtk_tree_selection_select_iter [ 0.00%] [ 0.00%] gtk_tree_store_new [ 0.00%] [ 0.00%] gtk_tree_store_set [ 0.00%] [ 0.00%] vte_terminal_set_font [ 0.00%] [ 0.00%] __close [ 0.00%] [ 0.00%] __pthread_rwlock_rdlock [ 0.00%] [ 0.00%] gtk_tree_view_scroll_to_cell [ 0.00%] [ 0.00%] g_object_notify_by_pspec [ 0.00%] [ 0.00%] g_strdup_printf [ 0.00%] [ 0.00%] gtk_tree_model_get_path [ 0.00%] [ 0.00%] gtk_tree_model_get_type [ 0.00%] [ 0.00%] In file /lib/aarch64-linux-gnu/ld-2.24.so [ 0.00%] [ 0.00%] gtk_window_set_transient_for [ 0.00%] [ 0.00%] g_initable_new [ 0.00%] [ 0.00%] __socket [ 0.00%] [ 0.00%] gtk_label_get_type [ 0.00%] [ 0.00%] __read_nocancel [ 0.00%] [ 0.00%] std::basic_filebuf<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode) [ 0.00%] [ 0.00%] gtk_progress_bar_pulse [ 0.00%] [ 0.00%] gtk_widget_queue_allocate [ 0.00%] [ 0.00%] g_main_context_iteration [ 0.00%] [ 0.00%] malloc [ 0.00%] [ 0.00%] OpProgress::OverallProgress(unsigned long long, unsigned long long, unsigned long long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) [ 0.00%] [ 0.00%] __libc_start_main [ 0.00%] [ 0.06%] g_signal_emit_valist [ 0.00%] [ 0.04%] In file /usr/lib/aarch64-linux-gnu/libgtk-3.so.0.2200.11 [ 0.00%] [ 0.03%] In file /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.5000.3 [ 0.00%] [ 0.02%] g_signal_emit_by_name [ 0.00%] [ 0.01%] g_signal_emit [ 0.00%] [ 0.01%] In file /usr/lib/aarch64-linux-gnu/libgdk-3.so.0.2200.11 [ 0.00%] [ 0.01%] gtk_main [ 0.00%] [ 0.01%] main [ 0.00%] [ 0.01%] g_main_context_dispatch [ 0.00%] [ 0.01%] __libc_start_main [ 0.00%] [ 0.01%] g_main_loop_run [ 0.00%] [ 0.01%] In file /lib/aarch64-linux-gnu/libglib-2.0.so.0.5000.3 [ 0.00%] [ 0.00%] g_cclosure_marshal_VOID__BOXEDv [ 0.00%] [ 0.00%] gtk_main_iteration [ 0.00%] [ 0.00%] gtk_main_do_event [ 0.00%] [ 0.00%] gtk_event_controller_handle_event [ 0.00%] [ 0.00%] ffi_call [ 0.00%] [ 0.00%] - - kernel - - [ 0.00%] [ 0.00%] ffi_call_SYSV [ 0.00%] [ 0.00%] g_cclosure_marshal_generic_va [ 0.00%] [ 0.00%] g_closure_invoke [ 0.00%] [ 0.00%] g_main_context_iteration [ 0.00%] [ 0.00%] In file /lib/aarch64-linux-gnu/libc-2.24.so [ 0.00%] [ 2.21%] [/usr/lib/xorg/Xorg] [ 0.00%] [ 2.04%] [SSL Cert #49] [ 0.00%] [ 0.92%] [/usr/lib/firefox-esr/firefox-esr] [ 0.00%] [ 0.80%] [sysprof] [ 0.00%] [ 0.46%] [lxpanel] [ 0.00%] [ 0.22%] [python2.7] [ 0.00%] [ 0.21%] [dpkg] [ 0.00%] [ 0.17%] - - kernel - - [ 0.00%] [ 0.16%] [pycompile] [ 0.00%] [ 0.15%] [http] [ 0.00%] [ 0.14%] [kworker/dying] [ 0.00%] [ 0.08%] [pcmanfm] [ 0.00%] [ 0.07%] [dpkg-query] [ 0.00%] [ 0.05%] [mmcqd/1] [ 0.00%] [ 0.04%] [openbox] [ 0.00%] [ 0.04%] [gdbus] [ 0.00%] [ 0.03%] [modprobe] [ 0.00%] [ 0.02%] [mc] [ 0.00%] [ 0.02%] [dpkg-deb] [ 0.00%] [ 0.02%] [apt-extracttemp] [ 0.00%] [ 0.01%] [urxvt] [ 0.00%] [ 0.01%] [/usr/sbin/haveged] [ 0.00%] [ 0.01%] [lsb_release] [ 0.00%] [ 0.01%] [ksoftirqd/0] [ 0.00%] [ 0.01%] [mandb] [ 0.00%] [ 0.01%] [kswapd0] [ 0.00%] [ 0.01%] [rm] [ 0.00%] [ 0.01%] [joe] [ 0.00%] [ 0.01%] [sh] [ 0.00%] [ 0.01%] [tar] [ 0.00%] [ 0.01%] [dpkg-split] [ 0.00%] [ 0.01%] [file] [ 0.00%] [ 0.01%] [jbd2/mmcblk1p1-] [ 0.00%] [ 0.01%] [avahi-daemon: running [rock64.local]] [ 0.00%] [ 0.00%] [/usr/lib/at-spi2-core/at-spi2-registryd] [ 0.00%] [ 0.00%] [/usr/bin/lxsession] [ 0.00%] [ 0.00%] [apropos] [ 0.00%] [ 0.00%] [man] [ 0.00%] [ 0.00%] [cfinteractive] [ 0.00%] [ 0.00%] [which] [ 0.00%] [ 0.00%] [/usr/sbin/ntpd] [ 0.00%] [ 0.00%] [/lib/systemd/systemd-journald] [ 0.00%] [ 0.00%] [/usr/bin/dbus-daemon] [ 0.00%] [ 0.00%] [bash] [ 0.00%] [ 0.00%] [/sbin/init] [ 0.00%] [ 0.00%] [sed] [ 0.00%] [ 0.00%] [dhclient-script] [ 0.00%] [ 0.00%] [/lib/systemd/systemd-logind] [ 0.00%] [ 0.00%] [/lib/systemd/systemd-udevd] [ 0.00%] [ 0.00%] [kworker/1:1] [ 0.00%] [ 0.00%] [hostname] [ 0.00%] [ 0.00%] [systemd-cgroups] [ 0.00%] [ 0.00%] [resolvconf] [ 0.00%] [ 0.00%] [/usr/sbin/cron] [ 0.00%] [ 0.00%] [debian-sa1] [ 0.00%] [ 0.00%] [run-parts] [ 0.00%] [ 0.00%] [python-dbus.pos] [ 0.00%] [ 0.00%] [/usr/bin/python3] [ 0.00%] [ 0.00%] [/usr/sbin/rsyslogd] [ 0.00%] [ 0.00%] [kworker/0:0] [ 0.00%] [ 0.00%] [sensible-editor] [ 0.00%] [ 0.00%] [pasystray] [ 0.00%] [ 0.00%] [pager] [ 0.00%] [ 0.00%] [python-crypto.p] [ 0.00%] [ 0.00%] [ksoftirqd/1] [ 0.00%] [ 0.00%] [avahi-autoipd] [ 0.00%] [ 0.00%] [cat] [ 0.00%] [ 0.00%] [python-xdg.post] [ 0.00%] [ 0.00%] [python-secretst] [ 0.00%] [ 0.00%] pam_sm_acct_mgmt [ 0.00%] [ 0.00%] [python-pyasn1.p] [ 0.00%] [ 0.00%] [python-keyrings] [ 0.00%] [ 0.00%] [python-gi.posti] [ 0.00%] [ 0.00%] [python-pip.post] [ 0.00%] [ 0.00%] [python-keyring.] [ 0.00%] [ 0.00%] [nm-applet] [ 0.00%] [ 0.00%] pam_sm_open_session [ 0.00%] [ 0.00%] gtk_module_init [ 0.00%] [ 0.00%] [python-idna.pos] [ 0.00%] [ 0.00%] [python-wheel.po] [ 0.00%] [ 0.00%] [python-pkg-reso] [ 0.00%] [ 0.00%] [python-enum34.p] [ 0.00%] [ 0.00%] [man-db.postinst] [ 0.00%] [ 0.00%] [cons.saver] [ 0.00%] [ 0.00%] [/sbin/dhclient] [ 0.00%] [ 0.00%] [locale] [ 0.00%] [ 0.00%] [python-six.post] [ 0.00%] [ 0.00%] [python-ipaddres] [ 0.00%] [ 0.00%] [python-setuptoo] [ 0.00%] [ 0.00%] [python-cryptogr] [ 0.00%] [ 0.00%] [/usr/lib/policykit-1/polkitd] [ 0.00%] [ 0.00%] In file /lib/aarch64-linux-gnu/security/pam_loginuid.so [ 0.00%] [ 0.00%] In file /lib/aarch64-linux-gnu/security/pam_env.so [ 0.00%] [ 0.00%] [/usr/lib/gvfs/gvfsd] [ 0.00%] [ 0.00%] [migration/1] [ 0.00%] [ 0.00%] [/usr/lib/aarch64-linux-gnu/sysprof/sysprofd] [ 0.00%] [ 0.00%] [migration/0] [ 0.00%] [ 0.00%] [/usr/lib/gvfs/gvfsd-trash] [ 0.00%] [ 0.00%] [kthreadd] [ 0.00%] [ 0.00%] In file /lib/aarch64-linux-gnu/libsystemd.so.0.17.0
    
    

    I'm not sure if the line ends will straighten out when I post but it spent 90% of its time in

    pkgTagFile::Jump(pkgTagSection&, unsigned long long)

    whatever that does.  I did one search and installed what I found, then shut it down.  I'll look for that in the source.

    textcap.txt

    sysprof_ss.gif

  13. Taking the compress out (of the /etc/apt files), deleting the cache, rebooting, didn't make any difference.  I got the source to Synaptic with the intention of trying to profile it to see where it's hanging up.  I bought the Rock64 to run the latest Gimp, I frequently build stuff that isn't in the debs.  I need search to work.  Spent a couple days trying to build firefox with 1 GB of RAM on a Pi, had to give up.  There are a lot of dependencies, you can find all of them by searching in Synaptic.  The deb Rust is too old, but install that and upgrade it.

     

    My 3-line interface file seems to work fine without NetworkManager interference.  I disabled it with systemctl.  All I need is:

    
    auto wlx0022c0cc0822
    
    iface wlx0022c0cc0822 inet dhcp
      wireless-essid Moto_lte
    
    

    So the interface name is always wlx and the MAC?  Interesting.

     

    Hmm:

    
    rock64# pwd
    /usr/src/misc/synaptic/synaptic-0.84.2
    rock64# grep -ir sql .
    ./README.tasks:database-server SQL database
    ./README.supported:database-server SQL database
    Binary file ./help/sv/figures/synaptic-repositories.png matches
    Binary file ./help/sv/figures/synaptic-packagedetails.png matches
    
    

    Oh, it's only in the examples of what Synaptic could install, I was hoping there was a plan to convert to SQL or capability to export to SQL.  Seems to be abandoned since 2012, the mailing list has been dead so far, no answer to the question I sent to it yesterday.

     

    Ughh, I'm getting texlive (1 GB) because I needed xmlto.

     

  14. 2 hours ago, Igor said:


    On Intel machine with SSD :) or on the same hardware with SD card? This would explain the diff.

     

    Rock64 has not a matured kernel support yet which means it can be anything while userspace is not much changed. We use upstream Debian base + few optimizations on the top which, I doubt, has anything to do with this.

     

    I don't use any Intel machines, my "big machine" is a Pi.   I was hoping the Rock64 would be.  I have a SD with Raspbian around still but for 3 weeks or so I've been running this arm64 Buster image.  It's pretty close to perfect, very stable, no surprises.  https://people.debian.org/~stapelberg/raspberrypi3/

    Sounds like he doesn't want to go on maintaining it, it's dated 2018-01-08. I've been doing updates and upgrades, which work fine.  In the sources.list are buster and unstable.  Runs on Pi hardware only though, I'm on a 3B.

     

    One thing I haven't tried is just deleting/moving the cache file and letting it get replaced.  I'll probably also turn off compression, but it's an option in at least 2 or 3 places.  Just looking at the arm64 Pi's files in /etc/apt there's no mention of compression.

     

    NetworkManager is about to get the axe I think, I don't like that or wicd.  It should have been able to run headless overnight but it kept dropping leases, I couldn't ssh to it.  I just use a simple interfaces file.  I don't have a USB KVM switch so only one machine gets hooked up at a time.

  15. I'm running Armbian on a 4 GB Rock64, downloaded and installed yesterday.  I've been using Debian/Raspbian/Armbian for about 10 years and I've really come to rely on Synaptic for searching and being able to make download scripts.  Not every day but about once a week especially if I'm setting up something (like this Rock64).

     

    This Synaptic's access to the package database seems incredibly slow.  A single search may take 20 minutes.  After installing something it reloads the list and shows it on the screen, that can be another 20 minutes.  During this time it's got 1 thread using 100% of one CPU.  Typing is sometimes impaired, window repainting usually.

     

    In this picture Synaptic was behind Firefox and I clicked on it to bring it to the foreground.  That still hadn't happened here (it finally did) and I wanted to screenshot it, so there are also bits of the screenshot utility being dragged off the screen.  Synaptic's using too much CPU for the screen to be redrawn.

     

    From my database experience it reminds me of one time I forgot to build an index on a table.  It can still be searched but very slowly.  Every access requires reading the whole thing over again.  I always thought it was strange there wasn't a normal SQL database somewhere, /var/cache/apt/pkgcache.bin may be it:

    
    rock64# file pkgcache.bin
    pkgcache.bin: APT cache data, version 11.0, little-endian, 68706 packages, 102453 versions
    
    

    But I don't think it's possible to use the nice GUI editors like for PostgreSQL, MySQL, SqlLite on it.

     

    The page in Firefox was an interesting article at https://unix.stackexchange.com/questions/383999/why-are-some-packages-not-available-in-my-debian-jessie-installation

    about fixing some apt/synaptic problems but didn't help in this case.  Oh, and I'm now subscribed to the mailing list synaptic-devel@nongnu.org but I could be the only one.  The last Synaptic changes were in 2012.

     

    The problem seems peculiar to Armian, Synaptic works normally in Raspbian and Debian Buster.  Could be file permissions (but not obvious) or some PAM/Selinux/Apparmor thing.  The FileMagic (https://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_numbers_in_files on this pkgcache.bin is DC 76 FE 98.

    bad_repainting.gif

  16. OK, I found my Ralink adapter, it works fine.  Getting moved in now that I have connectivity.

     

    Why are searches in Synaptic so slow?  A Pi does them maybe 10 times as fast.  I like Synaptic for the searches, being able to see dev and doc addons, being able to build a list/script that calls wget for the actual downloads.  Then having that batch of files in a directory by themselves so you can copy them to another machine and dpgk -i to install, instead of having to download them all over again.

     

    Maybe I see it, the apt lists are kept as .lz4, that seems like a bad idea.  Maybe a couple scripts to uncompress and recompress them.  But I just installed some stuff with Synaptic and it's taking 20 minutes or more to get back to the index.  100% CPU usage on 1 core.  Ah, /etc/apt/apt.conf.d/02compress-indexes that's gotta go, probably.  Just need to find the politcally correct way to do it.

  17. Just trying to compare the nm output from the Buster driver with the Stretch driver.  If I'm not comparing the wrong files or something.  It looks like about the first 6 symbols are defined in both, after that the Stretch one has numbers instead of names.  But the numbers are drastically different too, the Stretch one looks like a list of pointers to pointers, the Buster one has addresses with more space between them.  One uses relocatable stuff and one doesn't?  I don't think I'll try using Buster ko files in Stretch.  They do look significantly different, like maybe there's a change that didn't get backported to Stretch?

     

    Then again I know that Raspbian's driver has been running for 9 days, that's not the Buster arm64 Debian driver.

     

    The Rock one is unreliable, so's the one Ayufan uses.  I could see my APs but not connect, then I could and did an apt-get update, but when I tried to install mc it had dropped out again.  Maybe I could connect the Rock to the phone over USB in the short term.  I've also got a little Ralink USB-wifi adapter somewhere.

    difff_pic.png

  18. 6 hours ago, Igor said:

    Then try to port the driver from Rpi to Rock64 kernel and it will work here as well. It can be done but it is some work. Again, our build tools provide an environment for this but it is still some work.

     

    Hmm, I'm sitting here at my arm64 Pi so I picked it up and plugged it in.  My hunch would be it's a kernel module.  Just wondering if I can borrow the one from this arm64 Debian.  But wouldn't it be the same driver supplied by Debian?

     

    dmesg says

    
    [41742.672963] usb 1-1.4: new high-speed USB device number 18 using dwc2
    [41742.778925] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=8176
    [41742.786034] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [41742.793620] usb 1-1.4: Product: 802.11n WLAN Adapter
    [41742.798853] usb 1-1.4: Manufacturer: Realtek
    [41742.803268] usb 1-1.4: SerialNumber: 00e04c000001
    [41743.129189] rtl8192cu: Chip version 0x10
    [41743.238901] rtl8192cu: Board Type 0
    [41743.242755] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
    [41743.250768] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
    [41743.257591] usb 1-1.4: firmware: failed to load rtlwifi/rtl8192cufw_TMSC.bin (-2)
    [41743.265322] usb 1-1.4: Direct firmware load for rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
    [41743.278513] usb 1-1.4: firmware: failed to load rtlwifi/rtl8192cufw.bin (-2)
    [41743.285755] usb 1-1.4: Direct firmware load for rtlwifi/rtl8192cufw.bin failed with error -2
    [41743.294478] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
    [41743.353149] ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
    [41743.354964] usbcore: registered new interface driver rtl8192cu
    
    

     

    lsmod | grep rtl says

    rtl8192cu              77824  0
    rtl_usb                24576  1 rtl8192cu
    rtl8192c_common        53248  1 rtl8192cu
    rtlwifi                81920  3 rtl_usb,rtl8192c_common,rtl8192cu
    mac80211              720896  3 rtl_usb,rtlwifi,rtl8192cu
    cfg80211              651264  3 mac80211,rtlwifi,brcmfmac
    usbcore               274432  10 usbnet,usbhid,usb_storage,rtl_usb,dwc2,usblp,smsc95xx,brcmfmac,uas,rtl8192cu
    
    

     

    locate rtl8192 | grep ko says

    
    /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192c/rtl8192c-common.ko
    /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/rtl8192ce.ko
    /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rtl8192cu.ko
    /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192de/rtl8192de.ko
    /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/rtl8192ee.ko
    /lib/modules/4.14.0-3-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rtl8192se.ko
    /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192c/rtl8192c-common.ko
    /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/rtl8192ce.ko
    /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rtl8192cu.ko
    /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192de/rtl8192de.ko
    /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/rtl8192ee.ko
    /lib/modules/4.16.0-1-arm64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rtl8192se.ko
    
    

     

    Probably the kernel version number has to match, the Rock seems to have 4.4.124-rk3328.

     

  19. For a couple weeks or so I've been happily using Stapleberg's arm64 Buster raspi image at https://people.debian.org/~stapelberg/raspberrypi3/, was wondering about doing that with the Rock64 if all else failed.  I found https://github.com/rockchip-linux/rkbin

    for firmware and hopefully drivers.  I've used debootstrap before but lucked out and didn't need to put any machine specific stuff in.  I have no experience fiddling with the way arms boot: uboot, etc.

     

    Hopefully I've got default.target symlinked to multi-user.target now so next time I try to boot I can at least see what's going on.  I think the only thing I changed was the interfaces file, I'm not sure why I get a black screen.  PAM hates me.  I 'd rather watch the bootup messages and type startx anyway.

     

    I've got a few rtl8192s, this one didn't work reliably with Ayufan's Debian either.  They seem to work in Pis OK.  I have 2 downstairs on a Pi and Zero that are mining away through them.  The names, yeah, I saw that page at freedesktop.org.  I thought in my dmesg it was using a name like rtl8192cu but that's not what ifconfig shows.

  20. OK, that booted.  And it's tty1.  After the password stuff it came up in xcfe(?) but my rtl8192 wasn't working, no network.  So I opened a terminal to find out what the interface was called, something that can only be copied and pasted, not typed or remembered.  Same thing Ayufan's version called it I think, 3 letters then 12 hex digits.  Made up an interfaces file by modifying one from  a Pi:

    
    auto wlx48022a9d4d57
    
    iface wlx48022a9d4d57 inet dhcp
      wireless-essid Moto_lte
    
    

    Tried to ifup it, didn't work.  So I decided to reboot, using the GUI, not just typing reboot in a terminal.

     

    Now it boots to a black screen with nothing on it.

     

    I started playing with Linux 20 years ago, spent 15 years using OpenBSD.  I don't like feeling coddled.  I don't want it to work like MS Windows, I just want it to work.  I'd actually almost prefer FVWM.  Anyway this seems to work better than Ayufan's.

  21. Mine didn't work either.  Stock 3 amp power supply, new High Endurance Sandisk 64 GB SD from B&H Photo.  Can't log in.  tty something 1 (or 0), might have been ttys1?  Wasn't paying attention, fairly sure there was a 1.  I didn't ctrl-alt-fn to another virtual console or anything.  Connected with a USB keyboard and HDMI monitor.

     

    I used dd, the only odd thing I did was bs=1M because I hoped it would go faster.  I'm trying to find Etcher source or arm64 to run on my arm64 Pi but when this fsck finishes I'll start dd without telling it a blocksize.  Rarely have a problem using dd.

     

    But /etc/securetty?  I'll look at that in a reader if it won't boot again.  Really getting tired of falling over security, maybe I should try Arch again.  Securetty, PAM, Selinux, AppArmor.  I don't want/need any of that stuff.

     

    Hmm, without any block size:

    dd if="Armbian_5.42_Rock64_Debian_stretch_default_4.4.124_desktop.img" of=/dev/sdb
    6799360+0 records in
    6799360+0 records out
    3481272320 bytes (3.5 GB, 3.2 GiB) copied, 1030.04 s, 3.4 MB/s

     

  22. On a Pi when do this you need to make a couple changes before it will boot.  The drive will probably become /dev/sda (with partition numbers).  Mount the drive so you can work on it,  then edit the /etc/fstab (the one on the hard drive, not the one on your sd card.  The perspective is about to change, instead of root being on something like /dev/mmcblk0p2 it's going to be on probably /dev/sda2.  Change that in fstab.  See the fstab man page if in doubt.  Unmount the partition when you're done.

     

    I don't have my Rock running right now but if it has a boot partition you need to edit cmdline.txt (again,be sure it's the one on the hard drive, not your sd one).  So mount the 1st partition (/dev/sda1 probably).  Open cmdline.txt in your text editor and where it says root=/dev/mmcblk0p change that to root=/dev/sda1. Unmount the partition.

     

    I've seen my rock64 under Ayufan's Debian and Ubuntu, both had 7 partitions, I don't know if that's common.  Most everything was in the last one, look at the sizes.

     

    I had mine working but there seems to be some sort of timeout in the USB hardware on my Pi. When I walk away for 10 minutes or so it disconnects.  Different operating systems, an SD card in a reader instead of a hard drive, same thing happens.  Usually a crash and whatever was mounted needs to be fscked.  So I boot from SD, keep important stuff on the hard drive.  Good for changing operating systems or computers, just plug it in and mount it.  I plug it into my Pi  or my Rock64, works the same.  Handy once you get used to it.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines