LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Blogs
User Name
Password

Notices


  1. Old Comment

    Simple Bluetooth Keyboard How-To

    If you get something like this, when attempting to connect:
    Code:
    [bluetooth]# connect 80:58:F8:D2:9D:54
    Attempting to connect to 80:58:F8:D2:9D:54
    Failed to connect: org.bluez.Error.Failed
    Here's how I fixed it:

    As root:
    Code:
    apt-get install pulseaudio-module-bluetooth
    As regular user:
    Code:
    pulseaudio -k
    pulseaudio --start
    Then go back to "bluetoothctl -a" (as root) to attempt to connect.

    This fix was found here:

    https://unix.stackexchange.com/quest...z-error-failed
    Posted 09-11-2017 at 10:35 AM by IsaacKuo IsaacKuo is offline
  2. Old Comment

    How to understand bikers

    It all perfectly makes sense, thanks for sharing!
    Posted 09-11-2017 at 07:10 AM by Philip Lacroix Philip Lacroix is offline
    Updated 09-11-2017 at 11:34 AM by Philip Lacroix
  3. Old Comment

    linuxgalaxy.org down for cleaning and upgrades.

    @Habitual
    (1) No idea why you bothered to post. (2) No idea why I am bothering to respond.

    What part of "hobby server" do you not understand? There is nothing "routine" about this vintage box or my use of it as a learning tool. And yes, cleaning, since I am not in the habit of lying to people. As I said, instead of depending on "the cloud" to host links when I post on LQ, I use my own domains. If you don't trust linuxgalaxy.org then go to koenigcomputers.com which is hosted by a professional organization that does "Routine Maintenance" but never, ever, "cleaning."

    No one is forcing you to access my hobby web sites. There are far better resources for Slackware and Linux in general.
    Posted 09-10-2017 at 12:56 AM by kingbeowulf kingbeowulf is offline
  4. Old Comment

    linuxgalaxy.org down for cleaning and upgrades.

    I'd never visit a site labeled as needing "cleaning".
    Sorry, I suggest the phrase "Routine Maintenance" and leave it at that.

    Good Luck.
    Posted 09-08-2017 at 10:57 AM by Habitual Habitual is offline
    Updated 09-08-2017 at 03:01 PM by Habitual
  5. Old Comment

    Everyday Shortcuts

    Quote:
    Originally Posted by the dsc View Comment
    Good tips, thanks. Just googling by "divisible by 7" presents as the first result an excerpt from some site:



    This other site presents yet an weirder one:



    Math is just weird.
    Thanks for the additional references.
    Posted 09-07-2017 at 09:06 AM by rtmistler rtmistler is offline
  6. Old Comment

    Simple Bluetooth Keyboard How-To

    Not entirely related, but I'm putting this here because it's convenient for my notes:

    For a slate computer, it is convenient to use Unified Remote to turn a smart phone into a bluetooth keyboard/mouse/etc. However, with Debian 9 the version of bluez is too modern to work with SDP out-of-box. I found a fix on this page:

    https://bbs.archlinux.org/viewtopic.php?id=201672

    the steps are:

    Step 0) Pair with the phone as above (this will pair them, but without SDP Unified Remote still won't work).

    Step 1) Edit /etc/systemd/system/dbus-org.bluez.service
    Code:
    ExecStart=/usr/lib/bluetooth/bluetoothd --compat
    Step 2) Run:
    Code:
    systemctl daemon-reload
    systemctl restart bluetooth
    chmod 777 /var/run/sdp
    Step 3) Open up Applications -> Internet -> Unified Remote, and click on RESTART SERVER button.
    Posted 09-06-2017 at 02:47 PM by IsaacKuo IsaacKuo is offline
  7. Old Comment

    Slackware n00b wants: live for Yumi, and a .vdi

    Thanks. The exact search keyword I needed is: liveslak (exact spelling required)
    I'll go try that, but yumi doesn't support any slackware, and I don't want to disturb other things yumi wrote on usb.
    (Here, near bottom of page, 4th tab is 'supported distros'. I wrote to them, suggesting adding slackware)
    From search: liveslak yumi, I found this, with mention of problems with yumi.
    Posted 09-06-2017 at 01:41 PM by !!! !!! is offline
    Updated 09-06-2017 at 01:46 PM by !!!
  8. Old Comment

    Slackware n00b wants: live for Yumi, and a .vdi

    Indeed, liveslak is the way to go. It is Slackware64-current and available in standard to a variety of DEs to bleeding edge plasma5. I use it in my Win7 work laptop Dell Latitude e7440 booting of the built in sdcard slot. Recommended.
    Slackware Live Edition
    Posted 09-05-2017 at 06:17 PM by kingbeowulf kingbeowulf is offline
    Updated 09-05-2017 at 06:18 PM by kingbeowulf (spelling)
  9. Old Comment

    linuxgalaxy.org down for cleaning and upgrades.

    We're back up on www.linuxgalaxy.org. Ulog is pitching a fit for some reason in the firewall script. For now, regular firewall logging is running. The site my pop on/off over the next few days as I tweak a few items.
    Posted 09-05-2017 at 06:09 PM by kingbeowulf kingbeowulf is offline
  10. Old Comment

    Slackware n00b wants: live for Yumi, and a .vdi

    Ever tried Slackware live from AlenBOB?
    Posted 09-04-2017 at 05:29 AM by SCerovec SCerovec is offline
  11. Old Comment

    Poll? Are you: cloud-savvy, cli&os/code-savy, just end-user?

    Given how much attention cloud storage and computing gets in general, I think it would be interesting to see how the Linux crowd thinks about this.
    Posted 09-03-2017 at 07:42 PM by flshope flshope is offline
  12. Old Comment

    RAMBOOT with continuous rsync synchronization

    If you experienced no significant speed up in loading time, then that means that the applications you're loading are already heavily CPU limited rather than disk speed limited.

    Loading 17GB in 200s means a read speed of about 85MB/sec. Honestly, that's not very good. It may be the result of your RAID and file system not being very efficient at reading many small files. Web browser caches are particularly bad for this (which is why I tend to put /home/kuo/.cache on its own separate tmpfs or on an SSD). You'd probably find a huge improvement in boot time by using a compressed tarball instead of this rsync synchronization, but ... really, what's the point? The real life performance gain in your use case is practically nonexistent.
    Posted 08-30-2017 at 02:31 AM by IsaacKuo IsaacKuo is offline
  13. Old Comment

    RAMBOOT with continuous rsync synchronization

    Quote:
    To determine whether the thing is working properly, use "df" to see that your "/" file system is indeed a tmpfs file system.
    OK, that explains why it reported tmpfs on / as 30G with 17G in use.

    That being said, I did not see any improvement in the loading speed of apps:
    GIMP - ~2sec from SSD and ramboot
    LibreOffice ~3 sec from SSD and ramboot

    KDE took about the same time to reach the desktop. I did not check the actual ~ time.

    Code:
    tar cv . | (cd ${rootmnt} ; tar x)
    This is where my additional boot time is spent. All 200s or so.
    Posted 08-29-2017 at 09:13 PM by towheedm towheedm is offline
    Updated 08-29-2017 at 09:19 PM by towheedm
  14. Old Comment

    RAMBOOT with continuous rsync synchronization

    The code in this How-To does not create any tarball. It uses a piped pair of tar commands instead of "cp -vax" because "cp" just doesn't have enough juice to do the job in the limited initrd environment.

    As for your RAM usage - if you use "free" to determine your ram usage, you will not see tmpfs usage correctly reflected in it. Unfortunately, "free" thinks that anything in tmpfs is file system buffers. Truthfully, tmpfs is in fact implemented as file system buffers, but they have no backing file system so it's impossible for tmpfs "buffers" to get flushed to the non-existent backing file system.

    To determine whether the thing is working properly, use "df" to see that your "/" file system is indeed a tmpfs file system. You can also use a different tool to see your true RAM usage, including all tmpfs file systems. For example, gnome-system-monitor shows the correct RAM and swap usage.

    Note that even though there is no backing file system for tmpfs, tmpfs blocks CAN be swapped out to swap. This is useful because there is a lot of stuff in "/" which is rarely if ever accessed. This stuff will eventually get swapped out to swap if necessary.
    Posted 08-29-2017 at 08:16 PM by IsaacKuo IsaacKuo is offline
  15. Old Comment

    RAMBOOT with continuous rsync synchronization

    The problem for me is the -x option in the rsync command used for copying / to /ramback. Because /boot was on a different fs, it did not get copied over to /ramback. This was corrected.

    However, now once I booted, it added about 200s to my boot time and I did not see any decrease in RAM usage to account for the ramboot image in RAM. From your code, it appears that the tarball is built on every boot. According to df, I'm using 17G on my / fs.

    I should get about 1G/s read out of the RAID10 that / is on. I'm gonna re-benchmark and see the actual results. I can't recall the results from about 2 yrs ago.

    I'll return to this after my ZFS endeavours.
    Posted 08-29-2017 at 07:59 PM by towheedm towheedm is offline
    Updated 08-29-2017 at 08:01 PM by towheedm
  16. Old Comment

    Eclipse2017

    It was overrated. I ended up with a three day splitting headache.
    Posted 08-29-2017 at 09:43 AM by vmccord vmccord is offline
  17. Old Comment

    RAMBOOT with continuous rsync synchronization

    Quote:
    Originally Posted by towheedm View Comment
    Does not work for me. Selecting the RAMBOOT option still boots normally.
    If it boots normally, then the initrd.img-ramboot somehow failed to get the custom code for /usr/share/initramfs-tools/scripts/local

    Be very careful when doing "mkinitramfs -o /boot/initrd.img-ramboot" that the custom code is present in /usr/share/initramfs-tools/scripts/local at that time.

    I would recommend you repeat the instructions very carefully. You don't need to scrap the contents of /ramback first, because the rsync command will scrap any differences for you. Pay very close attention to the custom local.RAMBACK code and make sure to copy local.RAMBACK to local before the mkinitramfs step.

    Note that there are two branches to the "if" statement for mounting the root file system. My instructions only modify the branch where the root file system's type is known (which I think should really always be the case). But if for some reason you're still not getting it to work, maybe modify both branches of the "if" statement.

    Quote:
    I did not do a minimal install. I used my live system for the ramback dir. I have a separate /boot fs on /dev/md0 and / on /dev/md1.
    This requires a little adjusting, but it will still basically work fine. The important thing is to NOT mount /dev/md0 as /boot within /ramback/etc/fstab. IF YOU DO THIS, THEN YOU WILL EVENTUALLY BREAK YOUR NORMAL INSTALL. Why? Because at some point you'll boot up into your RAMBOOT system and do an apt update which updates initrd. This will overwrite your normal initrd and mess up your way to boot into your normal install!

    Instead, mount /dev/md0 to "/bootMD0" instead of "/boot". That way, apt will simply ignore the contents and never write anything to it. You can then manually copy whatever updated initrd/vmlinuz pair apt updates from /boot to /bootMD0/initrd.img-ramboot and /bootMD0/vmlinuz-ramboot

    Quote:
    On the first boot of the RAMBOOT option, firstly the /mnt dir was empty and /ramback/{vmlinux,initrd.img} were broken symlinks to /ramback/boot/vmlinuz-4.9.... and initrd.img-4.9......respectively. This was easily corrected but a reboot still rebooted normally.
    If the correct custom initrd code had been baked into initrd.img-ramboot, then it would have loaded up the file tree underneath /ramback into the tmpfs "/". This would have properly included /mnt/sda1 because of the instruction step:

    Code:
    ...
    mkdir /ramback/mnt/sda1
    ...
    As for the broken symlinks - it is important to NOT fix any broken symlinks underneath /ramback. Those symlinks need to be exactly the way they are after the rsync in order to load up properly into the tmpfs "/".
    Posted 08-29-2017 at 09:37 AM by IsaacKuo IsaacKuo is offline
  18. Old Comment

    RAMBOOT with continuous rsync synchronization

    Does not work for me. Selecting the RAMBOOT option still boots normally.

    I did not do a minimal install. I used my live system for the ramback dir. I have a separate /boot fs on /dev/md0 and / on /dev/md1.

    On the first boot of the RAMBOOT option, firstly the /mnt dir was empty and /ramback/{vmlinux,initrd.img} were broken symlinks to /ramback/boot/vmlinuz-4.9.... and initrd.img-4.9......respectively. This was easily corrected but a reboot still rebooted normally.
    Posted 08-29-2017 at 12:51 AM by towheedm towheedm is offline

  



All times are GMT -5. The time now is 09:52 AM.

Main Menu
Advertisement
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration