Closed 130s closed 3 years ago
Ubuntu Core
requests logon via ssh using key registered on SSO. Looks like I've made ssh key pair for Ubuntu SSO so using that in ~/.ssh/config
(just as https://stackoverflow.com/questions/2419566/best-way-to-use-multiple-ssh-private-keys-on-one-client) I was able to log on via ssh.
$ sudo snap install tmux
error: snap "tmux" is not available on stable but is available to install on the following
channels:
edge snap install --edge tmux
Please be mindful pre-release channels may include features not completely tested or
implemented. Get more information with 'snap info tmux'.
uo130s@localhost:~$ snap install --edge tmux
error: snap "tmux" requires classic confinement which is only available on classic systems
:/
This isn't going to be a production system at all so not being able to install tools like tmux
doesn't make much sense to me. Quickly giving up Core
, and will try Ubuntu 20.04 Server.
Then hit monitor issue similar to raspberrypi.stackexchange.com#q107943. (img taken from https://i.stack.imgur.com/ocZN9.jpg)
$ arp -na | grep -i "b8:27"
? (192.168.0.28) at b8:27:eb:32:f5:54 [ether] on wlp4s0
? (192.168.0.28) at b8:27:eb:32:f5:54 [ether] on enp5s0f2
These are different device (RPi2), so looks like RPi3 is not even connected to LAN yet.
Answer https://raspberrypi.stackexchange.com/a/116529/58336 solved distorted HDMI monitor issue.
Now I see:
BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6) buit-in shell (ash)
Enter 'help' for a list of built-in commans.
(initramfs)
(initramfs)
(initramfs) _
Then exit
ing as recommended in https://askubuntu.com/questions/741109/ubuntu-15-10-busybox-built-in-shell-initramfs-on-every-boot doesn't take me anywhere.
(initramfs) exit
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
:
Then once again I forgot RPi3 is 64b board, but for RPi3 32b might be still recommendable according to https://ubuntu.com/download/raspberry-pi
32 bit vs 64 bit
The Raspberry Pi 2 only supports 32 bits, so that’s an easy choice. However the Raspberry Pi 3 and 4 are 64 bit boards. According to the Raspberry Pi foundation, there are limited benefits to using the 64 bit version for the Pi 3 due to the fact that it only supports 1GB of memory; however, with the Pi 4, the 64 bit version should be faster.
xzcat ubuntu-20.04.1-preinstalled-server-armhf+raspi.img.xz | sudo dd of=/dev/mmcblk0 bs=32M
Seems to be working with only adding dtoverlay=vc4-fkms-v3d
in /system-boot/usercfg.txt
.
New problems! Either USB keyboard nor network devices seem to be working:
I see ubuntu: login
then slowly something keeps printed like:
INFO task kworker/3:1:146 blocked for more than 120 seconds
:
echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Cloud-init v.20.2-45-X-0ubuntu~20.04.1 running 'module:config' at Mon, 12 Oct
Cloud-init v.20.2-45-X-0ubuntu~20.04.1 finished at Mon, 12 Oct. Datasource DataSourceNoCloud [seed=/dev/mmcblk0p1][dsmode=net]. Up 616.01 seconds
As the log indicates, the OS has been almost up to 10 mins or so. Still network not blinking.
Too tired. Went back to Ubuntu Core 18.
$ xzcat ubuntu-core-18-armhf+raspi.img.xz | sudo dd of=/dev/mmcblk0 bs=32M
0+85561 records in
0+85561 records out
704222208 bytes (704 MB, 672 MiB) copied, 3.38824 s, 208 MB/s
$ sync
I have never been hugry for problems today...Now:
Cannot find the 'snap' command. This means something went wrong.
Reinstalled ubuntu core.
$ sudo mkfs.vfat -F32 -v /dev/mmcblk0p1
mkfs.fat 4.1 (2017-01-24)
/dev/mmcblk0p1 has 4 heads and 16 sectors per track,
hidden sectors 0x0800;
logical sector size is 512,
using 0xf8 media descriptor, with 524288 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 1 sector per cluster.
FAT size is 4033 sectors, and provides 516190 clusters.
There are 32 reserved sectors.
Volume ID is c5b1d3e8, no volume label.
$ xzcat ubuntu-core-18-armhf+raspi.img.xz | sudo dd of=/dev/mmcblk0 bs=32M
0+85839 records in
0+85839 records out
704222208 bytes (704 MB, 672 MiB) copied, 3.34935 s, 210 MB/s
$ sync
$ sudo umount /dev/mmcblk0p1
umount: /dev/mmcblk0p1: not mounted.
$ sudo umount /dev/mmcblk0p2
$ lsblk
This time that snap
error doesn't happen.
Then, for some reason ssh
gets rejected even with the ssh config https://github.com/130s/hut_10sqft/issues/474#issuecomment-707288209
Turned out wrong username. Now sshed in.
I want tmux
! So trying to enable classic
following https://askubuntu.com/questions/724026/how-to-get-snappy-enable-classic
$ sudo snap install classic --devmode --edge
error: cannot communicate with server: Post http://localhost/v2/snaps/classic: EOF
$ sudo snap install --channel=18/edge classic --devmode
error: cannot communicate with server: timeout exceeded while waiting for response
Disk full? I'm using 64GB SD card but I do not see that amount used at all.
uo130s@localhost:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 355M 0 355M 0% /dev
tmpfs 86M 12M 75M 13% /run
/dev/mmcblk0p2 393M 384M 0 100% /writable
/dev/loop0 46M 46M 0 100% /
/dev/loop1 190M 190M 0 100% /lib/modules
tmpfs 427M 4.0K 427M 1% /etc/fstab
tmpfs 427M 0 427M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 427M 0 427M 0% /sys/fs/cgroup
tmpfs 427M 0 427M 0% /mnt
tmpfs 427M 0 427M 0% /tmp
tmpfs 427M 0 427M 0% /var/lib/sudo
tmpfs 427M 0 427M 0% /media
/dev/loop2 25M 25M 0 100% /snap/snapd/8792
/dev/loop3 26M 26M 0 100% /snap/snapd/9612
/dev/loop4 12M 12M 0 100% /snap/pi/73
/dev/mmcblk0p1 253M 45M 208M 18% /boot/uboot
tmpfs 86M 0 86M 0% /run/user/1000
uo130s@localhost:~$
https://www.raspberrypi.org/forums/viewtopic.php?t=62977
You cannot use NTFS. The first partition must be FAT formatted for the chip to understand it, the Linux partition usually needs something like ext4 / f2fs to suitably work properly with both linux and SD cards!
So FAT32 I formatted with above is the culprit?
uo130s@localhost:~$ sudo fdisk -l
Disk /dev/loop0: 45.7 MiB, 47943680 bytes, 93640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop1: 189.2 MiB, 198361088 bytes, 387424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop2: 24.6 MiB, 25804800 bytes, 50400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop3: 25.5 MiB, 26705920 bytes, 52160 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop4: 11.5 MiB, 12013568 bytes, 23464 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x29e6a53d
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 526335 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 526336 124735487 124209152 59.2G 83 Linux
So /dev/mmcblk0p2
is seen with a good size. But in df
it's only small amount visible:
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 355M 0 355M 0% /dev
tmpfs 86M 12M 75M 13% /run
/dev/mmcblk0p2 393M 384M 0 100% /writable
/dev/loop0 46M 46M 0 100% /
/dev/loop1 190M 190M 0 100% /lib/modules
tmpfs 427M 4.0K 427M 1% /etc/fstab
tmpfs 427M 0 427M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 427M 0 427M 0% /sys/fs/cgroup
tmpfs 427M 0 427M 0% /mnt
tmpfs 427M 0 427M 0% /tmp
tmpfs 427M 0 427M 0% /var/lib/sudo
tmpfs 427M 0 427M 0% /media
/dev/loop2 25M 25M 0 100% /snap/snapd/8792
/dev/loop3 26M 26M 0 100% /snap/snapd/9612
/dev/loop4 12M 12M 0 100% /snap/pi/73
/dev/mmcblk0p1 253M 45M 208M 18% /boot/uboot
tmpfs 86M 0 86M 0% /run/user/1000
The following verifies the claim from raspberrypi.org/forums (which seems to be posted by senior guy at RPi org) above https://www.raspberrypi.org/documentation/installation/sdxc_formatting.md:
According to the SD specifications, any SD card larger than 32GB is an SDXC card and has to be formatted with the exFAT filesystem. This means the official SD Formatter tool will always format cards that are 64GB or larger as exFAT.
The Raspberry Pi's bootloader, built into the GPU and non-updateable, only has support for reading from FAT filesystems (both FAT16 and FAT32), and is unable to boot from an exFAT filesystem. So if you want to use NOOBS on a card that is 64GB or larger, you need to reformat it as FAT32 first before copying the NOOBS files to it.
uo130s@localhost:~$ cat /proc/filesystems
nodev sysfs
nodev tmpfs
nodev bdev
nodev proc
nodev cgroup
nodev cgroup2
nodev cpuset
nodev devtmpfs
nodev configfs
nodev debugfs
nodev tracefs
nodev securityfs
nodev sockfs
nodev bpf
nodev pipefs
nodev ramfs
nodev devpts
ext3
ext2
ext4
squashfs
vfat
nodev ecryptfs
fuseblk
nodev fuse
nodev fusectl
nodev mqueue
nodev pstore
nodev autofs
uo130s@localhost:~$ ls /lib/modules/$(uname -r)/kernel/fs
9p afs befs btrfs cifs dlm f2fs fscache hfs isofs lockd nfs_common nls omfs pstore quota shiftfs.ko udf
adfs aufs bfs cachefiles coda efivarfs fat fuse hfsplus jffs2 minix nfsd ntfs orangefs qnx4 reiserfs sysv ufs
affs autofs binfmt_misc.ko ceph cramfs efs freevxfs gfs2 hpfs jfs nfs nilfs2 ocfs2 overlayfs qnx6 romfs ubifs xfs
uo130s@localhost:~$ uname -r
5.3.0-1030-raspi2
uo130s@localhost:~$ uname -a
Linux localhost 5.3.0-1030-raspi2 #32~18.04.2-Ubuntu SMP Fri Jul 24 10:02:25 UTC 2020 armv7l armv7l armv7l GNU/Linux
raspi2
?? Hm.
Anyways, I might have f*ed up by re-formating SD card to FAT32...?
But the same raspberrypi.org/documentation/installation/sdxc_formatting reads FAT32 is enough, to me.
Other Options Linux and Mac OS
The standard formatting tools built into these operating systems are able to create FAT32 partitions; they might also be labelled as FAT or MS-DOS. Simply delete the existing exFAT partition and create and format a new FAT32 primary partition, before proceeding with the rest of the NOOBS instructions.
Gave up. Going down with rpi-imager
GUI tool :/.
$ sudo snap install rpi-imager
rpi-imager v1.4 from Alan Pope (popey) installed
$ rpi-imager &
[1] 29775
$
$ Qt: Session management error: None of the authentication protocols specified are supported
propsReply "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.3164\" (uid=1000 pid=29775 comm=\"rpi-imager \" label=\"snap.rpi-imager.rpi-imager (enforce)\") interface=\"org.freedesktop.DBus.Properties\" member=\"GetAll\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.NetworkManager\" (uid=0 pid=3059 comm=\"/usr/sbin/NetworkManager --no-daemon \" label=\"unconfined\")"
nmReply "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.3164\" (uid=1000 pid=29775 comm=\"rpi-imager \" label=\"snap.rpi-imager.rpi-imager (enforce)\") interface=\"org.freedesktop.NetworkManager\" member=\"GetDevices\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.NetworkManager\" (uid=0 pid=3059 comm=\"/usr/sbin/NetworkManager --no-daemon \" label=\"unconfined\")"
"Object path cannot be empty"
QObject::setParent: Cannot set parent, new parent is in a different thread
Available disk space for caching: 0 GB
mountutils: Reading /proc/mounts
mountutils: Couldn't read /proc/mounts
Drive: "/org/freedesktop/UDisks2/drives/SC64G_0xfd764bfb"
Device: "/org/freedesktop/UDisks2/block_devices/mmcblk0p2" belongs to same drive
Unmounted "/org/freedesktop/UDisks2/block_devices/mmcblk0p2" successfully
Device: "/org/freedesktop/UDisks2/block_devices/mmcblk0p1" belongs to same drive
Unmounted "/org/freedesktop/UDisks2/block_devices/mmcblk0p1" successfully
Device: "/org/freedesktop/UDisks2/block_devices/mmcblk0" belongs to same drive
Sector size: 512 Device size: 63864569856
Try to perform TRIM/DISCARD on device
BLKDISCARD successful
Image URL: "http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ubuntu-core-18-armhf+raspi.img.xz"
Received header: HTTP/1.1 200 OK
Received header: Date: Tue, 13 Oct 2020 10:02:50 GMT
Received header: Server: Apache/2.4.29 (Ubuntu)
Received header: Last-Modified: Wed, 12 Aug 2020 15:30:22 GMT
Received header: ETag: "12e83f10-5acafddae5f80"
Received header: Accept-Ranges: bytes
Received header: Content-Length: 317210384
Received header: Content-Type: application/x-xz
Received header:
Seems to be working ok so far. Not sure why reboot is scheduled though.
reboot scheduled to update the system
The system is going down for reboot at Tue 2020-10-13 10:09:37 UTC!
$ cat /proc/filesystems
nodev sysfs
nodev tmpfs
nodev bdev
nodev proc
nodev cgroup
nodev cgroup2
nodev cpuset
nodev devtmpfs
nodev configfs
nodev debugfs
nodev tracefs
nodev securityfs
nodev sockfs
nodev bpf
nodev pipefs
nodev ramfs
nodev devpts
ext3
ext2
ext4
squashfs
vfat
nodev ecryptfs
fuseblk
nodev fuse
nodev fusectl
nodev mqueue
nodev pstore
nodev autofs
uo130s@localhost:~$ ls /lib/modules/$(uname -r)/kernel/fs
9p afs befs btrfs cifs dlm f2fs fscache hfs isofs lockd nfs_common nls omfs pstore quota shiftfs.ko udf
adfs aufs bfs cachefiles coda efivarfs fat fuse hfsplus jffs2 minix nfsd ntfs orangefs qnx4 reiserfs sysv ufs
affs autofs binfmt_misc.ko ceph cramfs efs freevxfs gfs2 hpfs jfs nfs nilfs2 ocfs2 overlayfs qnx6 romfs ubifs xfs
uo130s@localhost:~$ uname -a
Linux localhost 5.3.0-1030-raspi2 #32~18.04.2-Ubuntu SMP Fri Jul 24 10:02:25 UTC 2020 armv7l armv7l armv7l GNU/Linux
uo130s@localhost:~$
Hm, fdisk
output doesn't seem to differ much since the previous regarding Linux partition, non-working installation.
$ sudo fdisk -l
Disk /dev/loop0: 45.7 MiB, 47943680 bytes, 93640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop1: 190 MiB, 199241728 bytes, 389144 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop2: 189.2 MiB, 198361088 bytes, 387424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop3: 24.6 MiB, 25804800 bytes, 50400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/loop4: 11.5 MiB, 12013568 bytes, 23464 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x29e6a53d
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 526335 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 526336 124735487 124209152 59.2G 83 Linux
Enabling classic
seems to be not trivial? Still do not want to give up tmux
.
$ snap install classic --edge --devmode
$ snap info classic
name: classic
summary: Classic environment
publisher: Canonical✓
store-url: https://snapcraft.io/classic
contact: snaps@canonical.com
license: unset
description: |
Classic environment
commands:
- classic
- classic.create
- classic.reset
snap-id: QbSFwGGAgvG8zHl9nWLY7vEee8lhgFsp
tracking: latest/edge
refresh-date: today at 10:16 UTC
channels:
latest/stable: –
latest/candidate: –
latest/beta: 16.04 2019-07-22 (42) 12kB devmode
latest/edge: ↑
18/stable: –
18/candidate: –
18/beta: –
18/edge: 18.04-0.1 2019-07-22 (48) 21MB devmode
installed: 16.04 (42) 12kB devmode
I'm still told I'm not on classic
. Can be future work.
$ snap install --edge tmux
error: snap "tmux" requires classic confinement which is only available on classic systems
OpenHAB seems to be installed w/o any problem via snap
. But its systemd
service not found. Hmm.
$ sudo systemctl daemon-reload
$ sudo systemctl start openhab2.service
Failed to start openhab2.service: Unit openhab2.service not found.
$ sudo systemctl start openhab.service
Failed to start openhab.service: Unit openhab.service not found.
$ sudo systemctl enable openhab2.service
Failed to enable unit: Unit file openhab2.service does not exist.
$
emacs
cannot be installed either without classic
confinement. It's a pain for me not being able to use these dev tools.
$ snap install emacs
error: snap "emacs" requires classic confinement which is only available on classic systems
So by being packaged as snap
, there seems to be a specific way to start a service from snap
first of all.
$ snap info openhab
name: openhab
summary: openHAB smart home server
publisher: openHAB Foundation e.V. (openhab)
store-url: https://snapcraft.io/openhab
contact: snaps@canonical.com
license: unset
description: |
openHAB - a vendor and technology agnostic open source automation software for your home.
commands:
- openhab.backup
- openhab.client
- openhab.help
- openhab.influx
- openhab.karaf
- openhab.restore
- openhab.start
- openhab.status
- openhab.stop
services:
openhab.influx-setup: oneshot, disabled, inactive
openhab.influxd: simple, disabled, inactive
openhab: simple, enabled, active
snap-id: WpdPxW72JupkC8XTgaJsig3LEHdrR56x
tracking: latest/stable
refresh-date: today at 10:19 UTC
channels:
latest/stable: 2.5.9 2020-10-01 (553) 161MB -
latest/candidate: 2.5.9 2020-10-01 (553) 161MB -
latest/beta: 2.5.9 2020-10-01 (553) 161MB -
latest/edge: 3.0.0.M1 2020-10-12 (581) 159MB -
installed: 2.5.9 (553) 161MB -
uo130s@localhost:~$ openhab.start
There is a Root instance already running with name openhab and pid 1743. If you know what you are doing and want to force the run anyway, export CHECK_ROOT_INSTANCE_RUNNING=false and re run the command.
$ ps -ef|grep -i openhab
root 811 1 0 10:29 ? 00:00:01 /bin/sh /snap/openhab/553/runtime/bin/karaf server
root 1743 811 18 10:30 ? 00:01:02 /snap/openhab/553/jre/bin/java -Dopenhab.home=/snap/openhab/553 -Dopenhab.conf=/var/snap/openhab/553/conf -Dopenhab.runtime=/snap/openhab/553/runtime -Dopenhab.userdata=/var/snap/openhab/553/userdata -Dopenhab.logdir=/var/snap/openhab/553/userdata/logs -Duser.home=/var/snap/openhab/553/ -Dfelix.cm.dir=/var/snap/openhab/553/userdata/config -Djava.library.path=/var/snap/openhab/553/userdata/tmp/lib -Djetty.host=0.0.0.0 -Djetty.http.compliance=RFC2616 -Dorg.ops4j.pax.web.listening.addresses=0.0.0.0 -Dorg.osgi.service.http.port=8080 -Dorg.osgi.service.http.port.secure=8443 -Djava.awt.headless=true -Djava.endorsed.dirs=/snap/openhab/553/jre/jre/lib/endorsed:/snap/openhab/553/jre/lib/endorsed:/snap/openhab/553/runtime/lib/endorsed -Djava.ext.dirs=/snap/openhab/553/jre/jre/lib/ext:/snap/openhab/553/jre/lib/ext:/snap/openhab/553/runtime/lib/ext -Dkaraf.instances=/var/snap/openhab/553/userdata/tmp/instances -Dkaraf.home=/snap/openhab/553/runtime -Dkaraf.base=/var/snap/openhab/553/userdata -Dkaraf.data=/var/snap/openhab/553/userdata -Dkaraf.etc=/var/snap/openhab/553/userdata/etc -Dkaraf.log=/var/snap/openhab/553/userdata/logs -Dkaraf.restart.jvm.supported=true -Djava.io.tmpdir=/var/snap/openhab/553/userdata/tmp -Djava.util.logging.config.file=/var/snap/openhab/553/userdata/etc/java.util.logging.properties -Dkaraf.startLocalConsole=false -Dkaraf.startRemoteShell=true -classpath /snap/openhab/553/runtime/lib/boot/org.apache.karaf.diagnostic.boot-4.2.7.jar:/snap/openhab/553/runtime/lib/boot/org.apache.karaf.jaas.boot-4.2.7.jar:/snap/openhab/553/runtime/lib/boot/org.apache.karaf.main-4.2.7.jar:/snap/openhab/553/runtime/lib/boot/org.apache.karaf.specs.activator-4.2.7.jar:/snap/openhab/553/runtime/lib/boot/osgi.core-6.0.0.jar org.apache.karaf.main.Main
uo130s 2738 1898 0 10:35 pts/0 00:00:00 grep --color=auto -i openhab
The OpenHAB's web site on rpi3-1 is unreachable. Probably snap's security setting?
Oops, it was just a bad port. Firefox automatically used https
, for which the port is 8443. Now I can open GUIs.
Getting too long without expecting. Porting other tasks to another tickets.
Looks like unfamiliarity with Ubuntu Core is causing pain. But Snap's future is unclear, it may turn well. Helpful article from Maker https://twitter.com/130s/status/1460825251814772737. I'll stick at least on rpi3-1 with it.
Purpose TBD.Wanna set it up quick so I may just go with the most common OS for RPi3.CoS