live-kernel-updater Not Updating Running Live System

Forum Forums New users New Users and General Questions live-kernel-updater Not Updating Running Live System

This topic contains 8 replies, has 3 voices, and was last updated by calinb Feb 14-1:03 am.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #18171
    Member
    Avatar
    calinb

    I think I might need BitJam’s help again. I’m doing some investigative groundwork to build a CNC system using LinuxCNC. I’ll need a preempt-RT kernel for my CNC hardware. Over at LinuxCNC, the devs are working on a Debian Stretch live boot .iso with an RT kernel and it might even be getting close to release, but the stable release is still on Wheezy. I’m not expecting much in the way of persistence features from the live LinuxCNC .iso so why not try antiX?

    I’m running antiX 17.3.1 frugal persist on my old Samsung Netbook (Atom) that still runs MX-16 from its hard disk. I found “Linux for modern PCs (meta-package), PREEMPT_RT” using Synaptic and it installed linux-image-4.9.0-8-rt-686-pae with the RT patch set. Next I downloaded BitJam’s cli tools and live-kernel-updater zip archives from GitHub (“sudo apt-get install” git didn’t work for git and I don’t know where to find it).

    Sadly, uname -r reveals that the new RT kernel is not running, even though live-kernel-updater reports that the RT kernel is the default. Here’s what I get from live-kernel-updater:

    Starting live-kernel-updater
    ===============================================================================
    Current running kernel is 4.9.146-antix.1-486-smp
                                                                                            
    Please select the system to update                                                      
    = The current Live System on sda1                                                       
    > sdb   59.5G Mass Storage Device                                                       
    Press <Enter> to select the highlighted entry                                           
    Use 'h' for help, 'r' to redraw, 'q' to quit                                            
    Will use running live system                                                            
    Found linuxfs file linuxfs in directory /antiX-Frugal-4.9.146-antix.1-486-smp
    Found:
      2 total live kernels 
      1 default live kernel      (4.9.0-8-rt-686-pae)
      1 old live kernel          (4.9.146-antix.1-486-smp)
    
      2 total installed kernels 
      0 new installed kernels 
                                                                                            
    Please select an action to perform                                                      
    > Rollback vmlinuz to 4.9.146-antix.1-486-smp (2019-01-29)                              
    > Update initrd using file /usr/lib/iso-template/initrd.gz                              
    > Quit                                                                                  
    Press <Enter> to select the highlighted entry                                           
    Use 'h' for help, 'r' to redraw, 'q' to quit                                            
    Press 'q' again to quit  
    =====================================================================
    /usr/local/bin/live-kernel-updater
            program: live-kernel-updater
            started: Wed Jan 30 01:34:28 EST 2019
            version: 2.00.11 (Mon Jan 15 08:26:50 MST 2018)
             kernel: 4.9.146-antix.1-486-smp
                 OS: antiX 17.3.1 (Helen Keller)
          found lib: /usr/local/lib/cli-shell-utils/cli-shell-utils.bash
        lib version: 2.20.01 (Mon Jan  7 20:46:14 MST 2019)
    ---------------------------------------------------------------------
    
    Found man page: live-kernel-updater.1
    Current running kernel is 4.9.146-antix.1-486-smp
    Will use running live system
    Found linuxfs file linuxfs in directory /antiX-Frugal-4.9.146-antix.1-486-smp
     > wait_for_file /live/boot-dev/antiX-Frugal-4.9.146-antix.1-486-smp/linuxfs
     > mkdir -p /run/live-kernel-updater/linux
     > mount -t squashfs -o loop,ro /live/boot-dev/antiX-Frugal-4.9.146-antix.1-486-smp/linuxfs /run/live-kernel-updater/linux
    Found:
      2 total live kernels
      1 default live kernel      (4.9.0-8-rt-686-pae)
      1 old live kernel          (4.9.146-antix.1-486-smp)
    
      2 total installed kernels
      0 new installed kernels
    
    "/var/log/live-kernel-updater.log" [readonly] 182 lines, 7616 characters
    

    Thanks much!
    -Cal

    #18206
    Forum Admin
    dolphin_oracle
    dolphin_oracle

    did you reboot after making the change? ( I assume yes, but thought I would ask anyway).

    #18216
    Member
    Avatar
    calinb

    Thanks for the question, DO, because I keep thinking that I forgot to do something (like select the desired kernel from a grub menu or similar) but I did remember to reboot!

    #18235
    Member
    Avatar
    calinb

    I did a couple of unnecessary things in the above so I decided to try again without any redundant steps.

    Last time, I rebooted after installing the RT kernel package with Synaptic and then again after remastering (and before running live-kernel-updater). At least that’s what I remember doing. I had also run the initrd installer redundantly (not realizing it had already been done).

    Thus, I decided to try again with a different approach.

    I used a pre-RT kernel Synaptic installation snapshot .iso to make a new bootable USB (so I wouldn’t need to configure my desktop and network with my preferences again).

    I booted without persistence and then did the following:

    1. apt-get update and dist-upgrade.
    2. Synaptic installation of the new RT kernel.
    3. remastered
    4. ran live-kernel-updater
    5. rebooted

    I obtained the screen in the attached file. 🙁 / 🙂 (at least the new kernel is installed).

    LinuxCNC forum members often have trouble getting the RT kernel to boot. Can this be fixed with some boot options?

    I might need to build an RT kernel from source using “make oldconfig” from antiX kernel source. I haven’t done that in many years (back in my Gentoo days). Arrghh!

    Thanks for any advice, as always.

    -Cal

    • This reply was modified 2 months, 2 weeks ago by calinb.
    • This reply was modified 2 months, 2 weeks ago by calinb.
    • This reply was modified 2 months, 2 weeks ago by calinb.
    #18240
    Member
    Avatar
    calinb

    Update: I successfully used live-kernel-updated to rollback my last (no persistence) kernel and it booted just fine. Guess I’ll go study the LinuxCNC forum and see if there are any kernel options I might try passing to that 4.9.0-8-rt-686-pae kernel.

    #18435
    Member
    Avatar
    calinb

    I’m putting this antiX live boot project on the back burner for a bit. I booted the LinuxCNC live Debian image, ran the included latency test and, sure enough, my laptop can’t run LinuxCNC acceptably well. (It has too much latency, which is typical of laptops). I now need to identify a low latency mobo from my old computer boneyard and build a suitable desktop system to run LinuxCNC. Then I’ll try to run LinuxCNC from a live antiX USB, perhaps using the frugal option, or maybe I’ll just install antiX to an old boneyard hard drive.

    #18579
    Forum Admin
    BitJam
    BitJam

    Sorry calinb, I was out sick for a while. FWIW, That error message you show indicates the problem may be with squashfs support in the RT kernel. When you install the kernel, the configuration should be in a file at /boot/config-$VERSION. A recent antiX kernel has this line CONFIG_SQUASHFS=y
    I think it would also be okay if the RT kernel had CONFIG_SQUASHFS=m

    Of course, it may be a different problem but that is where I’d look first. It is also possible they compiled something as a module that we expected to be built into the kernel. If we can track that down then that is something we could fix on our end. But I’d look for squashfs support first.

    I am a little surprised that a RT kernel is still required for CNC work. I was doing stuff like that 25 or 30 years ago on cheap 386 hardware with mechanical servo/feedback loops (I have a funny story about Microsoft’s “Quick”Basic which was their response to Turbo Pascal and Turbo-C. TL;DR: “Quick”Basic was ungodly slow doing 16-bit (or was it 32-bit?) integer arithmetic which was already built into the CPU! For every operation they converted the integers to floating point then did a floating point calculation and converted back to integers. But the little controller we were using had no FPU so it took about 1,000 times longer than needed). The speedup in computers since then has been incredible, largely due to SIMD that was added so computers could play video. An ordinary laptop is faster than a super computer I was using in the 90s.

    I’d imagine you could tweak some parameters and set priorities to get the low latency, etc that you need. OTOH, the people making the RT kernel are not idiots so there is probably a very good reason they are working on it.

    Usually, the slowest thing, by miles, is the seek time on hard drives. Unlike almost everything else computer-wise, it has decreased slightly but it has not followed Moore’s Law, not even close. Using a decent SSD should fix this, so too would using something like the “toram” option to put everything you need to run the system into RAM. Of course, this assumes you have enough RAM to do that.

    Context is worth 80 IQ points -- Alan Kay

    #18583
    Forum Admin
    BitJam
    BitJam

    AHA! I think I found the problem! I installed the RT kernel, did a live-remaster and hit the same error message. I had set “bp=e” so I get to a shell on errors. I then did dmesg | tail
    to look for a more detailed error message. It told me that the squashfs built into the kernel does not support the fast lz4 compression. I haven’t tried it yet but rolling back the kernel update (using live-kernel-updater on a different machine or the same machine with a different live-usb) and then re-doing the live-remaster with one of the slower forms of compression might solve the problem. I was able to manually mount the original linuxfs file with the new kernel so I am confident that using another form of compression in live-remaster will get you past this problem.

    Yes, I looked at the kernel config file and found: # CONFIG_SQUASHFS_LZ4 is not set
    so using a different type of compression when you live-remaster should get around this problem. You could also suggest to the RT devs that they enable this option since it is super fast compared to the alternatives.

    • This reply was modified 2 months ago by BitJam.

    Context is worth 80 IQ points -- Alan Kay

    #18587
    Member
    Avatar
    calinb

    Thanks so much for debugging my problem, BitJam! I hope you are feeling well. There’s no rush on this CNC project so please prioritize feeling well over live antiX/MX support for me. This will be a fairly long-term project–probably all summer, at least.

    Even though I don’t expect much from my old netbook or current laptop, I’ll be able to get some RT latency test numbers and test the method with the LinuxCNC tools. RT is needed to use the Ethernet interface. Most LinuxCNC users are probably using parallel port boards with the RTAI kernel.

    Funny–I used Turbo Pascal to control a big DAC board that I wire-wrapped about 35 years ago. I ran it off a PC-AT parallel port. My Masters Degree thesis at UCD was titled “A Microcomputer-Based Controller for a Liquid Crystal Lens.” I guess the problem with laptops is typically the BIOS stuff you can’t disable–things like power management and fan speed control. As an FYI to you or anyone else who stumbles upon my LinuxCNC thread here, here’s some info from http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HardwareDesign I think antiX would be perfect for LinuxCNC, in general. Maybe I’ll try to stir up some interest over in the LinuxCNC forum.

    Once again, thanks! I’ll keep you informed about my progress.

    3. Why isn’t there support for <interface>
    LinuxCNC supports two different styles of realtime, kernel-space realtime with RTAI and user-space realtime with PREEMPT-RT (called “uspace”). In RTAI, Linux hardware drivers cannot be used from the realtime context, so it is not possible to reuse them. “uspace” is new in LinuxCNC 2.7. For this reason, almost all hal hardware drivers have been written in the lowest possible terms: inb(), outb() and the like.

    3.1. Ethernet
    Several people have had positive experience with “uspace” realtime and UDP ethernet communication. However, realtime ethernet performance depends on the Linux network driver itself having good realtime performance.

    In principle, the RTAI realtime kernel has a network interface, RTnet. However, no one has ever submitted a driver that uses RTnet. It is not clear whether RTnet as written will work with HAL’s timing model.

    (Note: A working ethernet HAL driver using RTNet is currently being developed, see rt-8p8c.)

    • This reply was modified 2 months ago by calinb.
    • This reply was modified 2 months ago by calinb.
Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.