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

Notices


  1. Old Comment

    HOW-TO: Simple GRUB2 NFSroot (Debian 8 Jessie)

    This how-to still works in Debian 10 Buster

    Also, I confirm there's no need for the entry in /etc/network/interfaces - just comment out the ethernet entry (leaving only the loopback entry). This is very conveniently portable so it's one less thing to alter when copying a setup for another computer.
    Posted 07-19-2019 at 05:19 PM by IsaacKuo IsaacKuo is offline
  2. Old Comment

    Diskless PXE netboot How-To for Debian 8 Jessie

    BTW, I confirm this how-to still works in Debian 10 Buster.
    Posted 07-19-2019 at 05:17 PM by IsaacKuo IsaacKuo is offline
  3. Old Comment

    RAMBOOT with continuous rsync synchronization

    BTW, this still works in Debian 10 Buster.
    Posted 07-19-2019 at 05:16 PM by IsaacKuo IsaacKuo is offline
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. Old Comment

    NFS-RAMBOOT - How-To for Debian 9 Stretch

    Alternative State-save Method

    One annoying thing about NFS-RAMBOOT is that it takes a while to create a new image and it hogs network bandwidth. An alternative is to use rsync - which is very fast - to keep another copy of the "/" filetree on the server in sync with what's in RAM. Then, you run tar on the server to compress that filetree into the image tarball. This costs some extra space on the server, but it conserves network bandwidth and it keeps you going instead of waiting for the tarball to finish.

    - - - - - 8< - - - - - cute here - - - - - 8< - - - - -

    ON SERVER

    Create the filetree folder and optionally initially populate it with:
    Code:
    mkdir /netroot/ramback
    cd /netroot/ramback/
    tar xzf /netroot/ramboot/image.tar.gz
    Make a utility script to compress a new tarball for use later:
    Code:
    #!/bin/sh
    rm -vi /netroot/ramboot64/image.tar.gz
    cd /netroot/ramback/
    tar cvzf /netroot/ramboot64/image.tar.gz --one-file-system .
    - - - - - 8< - - - - - cute here - - - - - 8< - - - - -

    ON CLIENT

    Use the following command whenever you want to save the current OS state to /netroot/ramback:

    Code:
    rsync -vaxAX --delete /. /netroot/ramback/
    If you want, you can run the tarball utility script on the server each and every time you sync up. Or you can just run the utility script once in a while. Or you can just run the utility script shortly before you intend to (re)boot the client.

    The bottom line is that saving the OS state with rsync is very fast and efficient, and the tarball compression doesn't really need to be done so often. Compression is still useful, though, because it reduces client boot time and network bandwidth use.
    Posted 08-04-2017 at 02:18 PM by IsaacKuo IsaacKuo is offline
  13. Old Comment

    NFS-RAMBOOT - How-To for Debian 9 Stretch

    Random note on NFS shares - it seems that in Debian 9 things can get funny if network-manager is installed and depending on the settings in /etc/network/interfaces...

    Basically, resolve.conf might be broken, which may interfere with mounting nfs shares, or the interface itself might only come up too late in the boot sequence to mount the nfs shares. This can delay bootup by the 1.5 minutes it takes to timeout nfs share mounting.

    The workaround I've come up with is:

    1) Use apt-get to remove network-manager

    Code:
    apt-get remove --purge network-manager
    apt-get autoremove --purge
    2) create/edit /etc/resolve.conf if necessary to something like:
    Code:
    nameserver 192.168.1.1
    Replace with your gateway IP address.

    Of course, if you use /etc/hosts to specify the IP addresses of the nfs share computers, then this won't really muck up mounting of nfs shares. But name resolution is critical for accessing servers out there on the internet...
    Posted 07-04-2017 at 10:11 AM by IsaacKuo IsaacKuo is offline
  14. Old Comment

    RAMboot How-To for Debian 8 Jessie

    If you have 3GB or less of RAM, and you're looking for places to shave some tmpfs drive space:

    1) Move /usr/share/doc onto a local drive or nfs mount, or simply delete it entirely (software updates will tend to put stuff back into it). This can save about 100MB, which is a big deal if space is tight. According to the Debian standards, all software is required to not break if /usr/share/doc is not present.

    2) Move /home/<user>/.cache/chromium and other web browser caches onto a local drive or nfs mount. A symlink will work. This can save over 100MB. Even if it's a bit slower than local ram, it's likely you'll never notice since it's still a lot faster than pulling off the internet and web browser speed tends to be limited by the speed of downloading the bits necessary off the internet anyway.

    3) Move /home/<user>/.config/chromium and other web browser config onto a local drive or nfs mount. A symlink will work. This actually might not save much space, if you don't use lots of heavy plugins or whatever. But it's nice for you to be able to resume where you left off web browsing in case of power failure. Just make sure to apt to the latest version of the web browser before running it after a power failure. Otherwise, you might lose stuff if you try to run chromium with an older version than what's in the .config save (I learned this the hard way).

    Moving the web browser cache/config off to an nfs share is a particularly good fit, because if the network is down you're not doing any web browsing anyway.

    With these tricks, you can reduce the size of tmpfs / by well over 200MB.
    Posted 07-02-2017 at 04:15 AM by IsaacKuo IsaacKuo is offline
  15. Old Comment

    NFS-RAMBOOT - How-To for Debian 9 Stretch

    If the client has 3GB or less of RAM, and you're looking for places to shave some tmpfs drive space:

    1) Move /usr/share/doc onto a local drive or nfs mount, or simply delete it entirely (software updates will tend to put stuff back into it). This can save about 100MB, which is a big deal if space is tight. According to the Debian standards, all software is required to not break if /usr/share/doc is not present.

    2) Move /home/<user>/.cache/chromium and other web browser caches onto a local drive or nfs mount. A symlink will work. This can save over 100MB. Even if it's a bit slower than local ram, it's likely you'll never notice since it's still a lot faster than pulling off the internet and web browser speed tends to be limited by the speed of downloading the bits necessary off the internet anyway.

    3) Move /home/<user>/.config/chromium and other web browser config onto a local drive or nfs mount. A symlink will work. This actually might not save much space, if you don't use lots of heavy plugins or whatever. But it's nice for you to be able to resume where you left off web browsing in case of power failure. Just make sure to apt to the latest version of the web browser before running it after a power failure. Otherwise, you might lose stuff if you try to run chromium with an older version than what's in the .config save (I learned this the hard way).

    Moving the web browser cache/config off to an nfs share is a particularly good fit, because if the network is down you're not doing any web browsing anyway.

    With these tricks, you can reduce the size of tmpfs / by well over 200MB.
    Posted 07-02-2017 at 04:14 AM by IsaacKuo IsaacKuo is offline
    Updated 07-02-2017 at 04:15 AM by IsaacKuo
  16. Old Comment

    HOW-TO: Simple GRUB2 NFSroot (Debian 8 Jessie)

    BTW, it may not be necessary to have the entry in /etc/network/interfaces at all. It seems to work fine without it.
    Posted 06-28-2017 at 04:37 AM by IsaacKuo IsaacKuo is offline
  17. Old Comment

    RAMboot How-To for Debian 8 Jessie

    I have confirmed that other than removing grub-pc (instead of just moving grub.cfg), everything here works in Debian 9 Stretch.
    Posted 06-27-2017 at 04:44 AM by IsaacKuo IsaacKuo is offline
  18. Old Comment

    HOW-TO: Simple GRUB2 NFSroot (Debian 8 Jessie)

    More Debian 9 Stretch notes:

    - - - - - RESOLV.CONF PROBLEMS - - - -

    It seems that network-manager messes up name resolution with network booting. I haven't figured out an elegant solution yet, but here's what I've got...

    Code:
    apt-get remove --purge grub-pc network-manager
    apt-get autoremove --purge
    After doing this, manually create /etc/resolv.conf with something like "vi /etc/resolv.conf" (or you can edit the file on the file server, with something like "vi /netroot/etc/resolv.conf")

    Make /etc/resolve.conf look something like this:
    Code:
    nameserver 10.42.0.1
    Typically, you'll want to put the ip address of your router for the nameserver.




    - - - - - NEW ETHERNET DEVICE NAMING CONVENTION - - - -

    Stretch no longer uses "eth0" style names. It will instead be something like "enp0s25", which you can determine by using the command:

    Code:
    ip link list
    So, you'll want to create (or modify) the /etc/network/interfaces entry to look something like:

    Code:
    ###allow-hotplug eth0
    iface enp0s25 inet dhcp
    - - - - - SUMMARY - - - - -

    So basically:

    1) Use enp0s25 style names for the ethernet link, rather than eth0 style name

    2) After booting up to the NETROOT install, apt-get remove grub-pc network-manager

    3) Manually create /etc/resolv.conf

    Everything else works as per the How-To
    Posted 06-27-2017 at 04:16 AM by IsaacKuo IsaacKuo is offline
    Updated 06-27-2017 at 08:35 AM by IsaacKuo
  19. Old Comment

    Diskless PXE netboot How-To for Debian 8 Jessie

    Notes on Debian 9 Stretch

    one quick initial note on Debian 9 Stretch:

    When upgrading from Debian 8 to Debian 9, it will want to update grub-pc. It will fail, because it will try to run update-grub even if /boot/grub/grub.cfg does not exist. More generally, my trick of renaming (or erasing) /boot/grub/grub.cfg might not work any more. It seems to try to run update-grub regardless of whether or not grub.cfg exists.

    So, instead of using this trick to prevent trying and failing update-grub (fails when it can't find the root canonical path), do this instead:

    After booting up into the PXE Netboot machine, uninstall grub-pc with:

    Code:
    apt-get remove grub-pc
    apt-get autoremove --purge
    If you don't do this, then it's not really a problem. It's just that every time you do an update or install software with apt-get, it will complain that it can't finish installing grub-pc. If you don't mind the annoyance of this every time, you can just leave grub-pc semi-installed.
    Posted 06-22-2017 at 08:45 AM by IsaacKuo IsaacKuo is offline
  20. Old Comment

    HOW-TO: Simple GRUB2 NFSroot (Debian 8 Jessie)

    Notes on Debian 9 Stretch

    one quick initial note on Debian 9 Stretch:

    When upgrading from Debian 8 to Debian 9, it will want to update grub-pc. It will fail, because it will try to run update-grub even if /boot/grub/grub.cfg does not exist. More generally, my trick of renaming (or erasing) /boot/grub/grub.cfg might not work any more. It seems to try to run update-grub regardless of whether or not grub.cfg exists.

    So, instead of using this trick to prevent trying and failing update-grub (fails when it can't find the root canonical path), do this instead:

    After booting up into the NFSROOT machine, uninstall grub-pc with:

    Code:
    apt-get remove grub-pc
    apt-get autoremove --purge
    If you don't do this, then it's not really a problem. It's just that every time you do an update or install software with apt-get, it will complain that it can't finish installing grub-pc. If you don't mind the annoyance of this every time, you can just leave grub-pc semi-installed.
    Posted 06-22-2017 at 08:44 AM by IsaacKuo IsaacKuo is offline

  



All times are GMT -5. The time now is 05:38 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