New firmware: 5.10.1 kernel
225 views
Skip to first unread message
Neil Brown
Dec 23, 2020, 10:51:39 PM12/23/20
to GnuBee
Hi all,
Linux 5.10, and 5.10.1, are out and I have a bit of time, so I've built firmware with this kernel which can be found in the usual places (https://neil.brown.name/gnubee/ with source code on github, user "neilbrown").
The code to auto-detect clock speed have changed substantially, and hopefully this new version has a better chance of landing upstream.
We used to use "uImage", but that is now compressed, and the u-boot on the gnubee cannot decompress it. So the "gbmake" file in gnubee-tools now builds and uses "uImage.bin" which is not compressed.
It would be nice to enable "ZBOOT" for the MT7621, which creates a self-extracting compressed kernel, so u-boot doesn't need to know how to uncompress it. I couldn't get that working, though I didn't spend long on it.
Note that I've seen two reports recently of people building their own kernel and the kernel failing to boot. This is most likely a compiler bug (could be bin-utils). I use gcc 7.2.0 and bin-utils 2.29.1. They might be a bit old now (gcc 10.2 and bin-utils 2.35.1 are available!) But I can confirm that the kernel they build works!
Have fun, enjoy the upgrade treadmill, and have a very merry Christmas.
NeilBrown
Matthias Urlichs
Dec 24, 2020, 6:38:03 AM12/24/20
to GnuBee
Thanks for your work on this, now let's push it into mainline ;-)
Is anybody working on teaching mainline U-Boot how to deal with these devices? I'm prepared to gift one to whoever manages to do that.
Anyway, I wrote an initrd scriptlet that finds my BOOT partition and then sources the /init script on it. The goal is to use kexec to start the "real" kernel instead of re-flashing all the time, for obvious reasons. I didn't actually test that yet, but since there now is a 5.10 kernel to play with … :-)
cat_to $R/etc/initramfs-tools/scripts/local-block/run-boot <<'END'
#!/bin/sh
PREREQS="mdadm start_all_lv"
# If we have a volume named BOOT, run its init script
case "${1:-}" in
prereqs)
echo "$PREREQS"
exit 0 ;;
esac
if test $$ -ne 1 ; then
echo ". /scripts/local-block/run-boot" >> /conf/param.conf
exit
fi
rm /conf/param.conf
modprobe nls_cp437
modprobe vfat
blkid -t LABEL=BOOT -o device | while read d ; do
if mount -t ext4 $d /root || mount -t vfat $d /root ; then
# this dance avoids holding a file descriptor on /root open
# but still keeps /root mounted, e.g. for setting up a fallback
if test -s /root/init ; then
cat /root/init >/conf/init
fi
if test -s /conf/init ; then
: run /init from $d
source /conf/init
: end /init from $d
fi
umount /root
fi
done
rmmod vfat
rmmod nls_cp437
END
$SU chmod 755 $R/etc/initramfs-tools/scripts/local-block/run-boot
#!/bin/sh
PREREQS="mdadm start_all_lv"
# If we have a volume named BOOT, run its init script
case "${1:-}" in
prereqs)
echo "$PREREQS"
exit 0 ;;
esac
if test $$ -ne 1 ; then
echo ". /scripts/local-block/run-boot" >> /conf/param.conf
exit
fi
rm /conf/param.conf
modprobe nls_cp437
modprobe vfat
blkid -t LABEL=BOOT -o device | while read d ; do
if mount -t ext4 $d /root || mount -t vfat $d /root ; then
# this dance avoids holding a file descriptor on /root open
# but still keeps /root mounted, e.g. for setting up a fallback
if test -s /root/init ; then
cat /root/init >/conf/init
fi
if test -s /conf/init ; then
: run /init from $d
source /conf/init
: end /init from $d
fi
umount /root
fi
done
rmmod vfat
rmmod nls_cp437
END
$SU chmod 755 $R/etc/initramfs-tools/scripts/local-block/run-boot
"start_all_lv" BTW is a minimal initrd script that simply calls "vgchange -ay" because if you have a labelled root the standard LVM boot script does nothing. :-(
Neil Brown
Dec 29, 2020, 12:06:38 AM12/29/20
to GnuBee
> Is anybody working on teaching mainline U-Boot how to deal with these devices?
I believe that would be difficult. The U-Boot we currently use contains binary blogs.
in "git://github.com/gnubee-git/GnuBee_PCx_uboot.git" one of the files uboot-5.x.x.x/mt7621_stage* is (I think) copied into the resulting u-boot image.
I suspect it contains SOC initialization code. Maybe we could disassemble it and work out what it does, but as I said: difficult.
I don't know of anyone trying.
vgn...@gmail.com
Dec 30, 2020, 11:37:18 AM12/30/20
to GnuBee
Great, looking forward to trying this.
I'm still stuck on 4.4 I think, but I'm replacing the HDD's with SSD's soon, so I'll be doing an update.
I remember last time I tried to update to a 5.x kernel, I couldn't connect to the device afterwards, I believe because the ethernet port names had been changed, so I gave up and went back to 4.4. How would I get around that this time? I don't have a USB-to-UART cable.
Thanks
Rob
Neil Brown
Dec 31, 2020, 8:38:29 PM12/31/20
to GnuBee
I remember last time I tried to update to a 5.x kernel, I couldn't connect to the device afterwards, I believe because the ethernet port names had been changed, so I gave up and went back to 4.4. How would I get around that this time? I don't have a USB-to-UART cable.
See the "Install / Rescue mode" section of the README.md in gnubee-tools.
In brief:
- Find a USB stick with a VFAT filesystem
- Create a file called "gnubee-config.txt" in the top level directory containing:
CONFIGURE_NET=yes
CONFIGURE_BLACK_IP=192.168.20.253
CONSOLE_SHELL=yes
Though you probably want to choose a different IP address for the BLACK_IP - Install the new firmware on your Gnubee (or maybe do this step first)
- Plug the USB stick with the config file, into the gnubee, and plug your network into the Black port
- Boot the gnubee and wait about a minute (in my test it was 50 seconds before ping started responding)
- ssh to the IP address you chose, and log in as "root" with password "GnuBee".
- mount your root filesystem somewhere (e.g. /mnt) and edit the files in /mnt/etc/network/interfaces.d/ to match your requirements.
The interfaces (which you can see in "ip link" arre "ethblack", "ethblue" and if you have a GB-PC2, "eth1" for the yellow port. - unmount /mnt, pull out the usb stick, and reboot.
Tom Hunt
Feb 20, 2021, 1:10:22 AM2/20/21
to GnuBee
I'm trying to boot off this on a GBPC2 using my LUKS-encrypted system (which works using your old 5.1 firmware). The kernel boots fine, but on opening the LUKS root device I get:
Enter passphrase for /dev/mmcblk0p1:
libgcc_s.so.1 must be installed for pthread_cancel to work
Aborted
libgcc_s.so.1 must be installed for pthread_cancel to work
Aborted
This happens both on first query during the normal boot process, and when I run a manual cryptsetup invocation from the busybox initrd shell.
Any idea what's going on here?
Jernej Jakob
Feb 20, 2021, 6:45:59 AM2/20/21
to Tom Hunt, GnuBee
I recently built the new image too, from what I can see the lib is
present in the chroot, but not in the final initramfs, so there's a bug
in the code that copies over the required libs
jernej@gentoo ~/git/gnubee-tools $ find linux/initramfs/lib/ -name
libgcc_s.so.1
jernej@gentoo ~/git/gnubee-tools $ find build/deb/chroot/ -name libgcc_s.so.1
build/deb/chroot/usr/lib/mipsel-linux-gnu/libgcc_s.so.1
The relevant part of the code is
https://github.com/neilbrown/gnubee-tools/blob/aecae55c966fb54a1ac88ecd55568bca5d67b63d/scripts/mkinitramfs#L178
which says ldd can't be run inside the chroot, which is why a hardcoded
list of libraries is used, this one is missing from it. Adding it here and
rebuilding the image would probably make it work.
The ldd in the chroot is a MIPS executable so it can't be ran on x86 without
an emulator/hypervisor.
In other build cases (e.g using a remote gnubee as source) ldd is used for
each binary so those probably work, though I haven't tested them.
present in the chroot, but not in the final initramfs, so there's a bug
in the code that copies over the required libs
jernej@gentoo ~/git/gnubee-tools $ find linux/initramfs/lib/ -name
libgcc_s.so.1
jernej@gentoo ~/git/gnubee-tools $ find build/deb/chroot/ -name libgcc_s.so.1
build/deb/chroot/usr/lib/mipsel-linux-gnu/libgcc_s.so.1
The relevant part of the code is
https://github.com/neilbrown/gnubee-tools/blob/aecae55c966fb54a1ac88ecd55568bca5d67b63d/scripts/mkinitramfs#L178
which says ldd can't be run inside the chroot, which is why a hardcoded
list of libraries is used, this one is missing from it. Adding it here and
rebuilding the image would probably make it work.
The ldd in the chroot is a MIPS executable so it can't be ran on x86 without
an emulator/hypervisor.
In other build cases (e.g using a remote gnubee as source) ldd is used for
each binary so those probably work, though I haven't tested them.
Jernej Jakob
Feb 20, 2021, 7:32:16 AM2/20/21
to Tom Hunt, GnuBee
Actually it looks like the from_chroot uses strings to scan the binary
itself for the libraries, which is how all of the libraries that would
be otherwise found via ldd are added.
https://github.com/neilbrown/gnubee-tools/blob/aecae55c966fb54a1ac88ecd55568bca5d67b63d/scripts/mkinitramfs#L65
The problem is that a library (libpthread.so.0) depends on another
library (libgcc_s.so.1).
So that list on L178 is probably only for those 2nd-level dependencies.
Maybe scanning all the libs with strings or ldd via the same process
used for binaries would work, and get rid of the hardcoded list?
A quick test using the same strings|grep command did yield the names of
libraries on libpthread.so.0 including libgcc_s.so.1. So highly likely
it would work.
itself for the libraries, which is how all of the libraries that would
be otherwise found via ldd are added.
https://github.com/neilbrown/gnubee-tools/blob/aecae55c966fb54a1ac88ecd55568bca5d67b63d/scripts/mkinitramfs#L65
The problem is that a library (libpthread.so.0) depends on another
library (libgcc_s.so.1).
So that list on L178 is probably only for those 2nd-level dependencies.
Maybe scanning all the libs with strings or ldd via the same process
used for binaries would work, and get rid of the hardcoded list?
A quick test using the same strings|grep command did yield the names of
libraries on libpthread.so.0 including libgcc_s.so.1. So highly likely
it would work.
Matthias Urlichs
Feb 20, 2021, 9:16:11 AM2/20/21
to gnu...@googlegroups.com
On 20.02.21 12:45, Jernej Jakob wrote:
> The ldd in the chroot is a MIPS executable so it can't be ran on x86 without
> an emulator/hypervisor.
… which is a bit silly, because that's very easily fixed by [installing
> The ldd in the chroot is a MIPS executable so it can't be ran on x86 without
> an emulator/hypervisor.
and then] copying /usr/bin/qemu-mipsel-static into the chroot.
--
-- Matthias Urlichs
penguinpages
Dec 11, 2021, 8:40:49 AM12/11/21
to GnuBee
Step1: flash firmware via vfat image from
Index of /gnubee (brown.name)
I have tried various images and I am sure it is user error... but trying to follow defined path and not seeing what I am missing
Sorry for spaming messages around on various forums.. I just am trying to find where / which spaces lurk the nerds I am looking for.
If there is an older image that is stable but solid in features: I am ok with that:
Features Needed:
1) NAS for NFS for six drives (sd card would be very helpful to meet capacity needs of data drives in R5)
2) two IPs on two VLANs (one for storage size for K8 cluster one on VM / host side for backup and plex media hosting). My original plan was eth0 +eth1 -> bond0 -> {vlan100 NIC 172.16.100.110/24} + {vlan 101 172.16.101.110/24} but I think I was told that this board has both NICS going into one chipset so LACP is not of value.. HA or aggregation.... so .. as long as I can split blue and black on different IPs.. I can set VLANs on switches
3) Raid 5 with SMART for drive error monitor
4) Serial console at boot (so I can debug and also repair / fsck / root cause
Thanks
penguinpages
Dec 11, 2021, 10:30:08 AM12/11/21
to GnuBee
As this forum lacks "edit" I guess I will post back updates . I decided to take USB serial port BACK to the Raspberry Pi ... which was not working stable before.. but now .. with this firmware .. I get full console AND shell response after boot (unlike putty with Windows.. which I guess I will table that head scratcher for another day)
Once it boots up.. I followed posting and run "config" . This is with sd 128GB Drive installed (and I did clean mkfs.ext4 /dev/sda1 mkfs.ext4 /dev/sda3) on it to clear out data:
#########
[ 13.283578] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 13.325840] mtk_soc_eth 1e100000.ethernet eth0: configuring for fixed/rgmii link mode
[ 13.341830] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 13.358689] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 13.568198] usb 1-2: new high-speed USB device number 2 using xhci-mtk
ip: SIOCGIFINDEX: No such device
[ 13.759849] hub 1-2:1.0: USB hub found
[ 13.767579] hub 1-2:1.0: 4 ports detected
/init: line 159: blkid: not found
/init: line 169: evtest: not found
[ 15.708217] Searching for partition GNUBEE-ROOT...
[ 15.717762] leds-gpio: probe of gpio-leds failed with error -16
/init: cd: line 10: can't cd to /sys/class/leds/gb-pc1:green:system: No such file or directory
findfs: unable to resolve 'PARTLABEL=GNUBEE-CRYPT-ROOT'
[ 18.563547] random: crng init done
findfs: unable to resolve 'LABEL=GNUBEE-ROOT'
/init: cd: line 10: can't cd to /sys/class/leds/gb-pc1:green:system: No such file or directory
/init: cd: line 10: can't cd to /sys/class/leds/gb-pc1:green:status: No such file or directory
BusyBox v1.30.1 (Debian 1:1.30.1-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ # lsblk
sh: lsblk: not found
/ # ip ad
1: lo: <LOOPBACK> mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast qlen 1000
link/ether 6a:0a:26:60:97:42 brd ff:ff:ff:ff:ff:ff
inet6 fe80::680a:26ff:fe60:9742/64 scope link
valid_lft forever preferred_lft forever
3: ethblack@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 90:50:5a:55:3a:50 brd ff:ff:ff:ff:ff:ff
4: ethblue@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 90:50:5a:55:3a:51 brd ff:ff:ff:ff:ff:ff
/ # config
Choose hostname (default gnubee.gnubee): pandora
## Hostname set to pandora
grep: /etc/shadow: No such file or directory
## root password changed
Configure network (ethblack) [s]tatic [d]hcp or [m]anual? s
IP address (192.168.1.10)? 172.16.100.110
Netmask (255.255.255.0)?
Gateway (172.16.100.1)?
[ 13.325840] mtk_soc_eth 1e100000.ethernet eth0: configuring for fixed/rgmii link mode
[ 13.341830] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 13.358689] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 13.568198] usb 1-2: new high-speed USB device number 2 using xhci-mtk
ip: SIOCGIFINDEX: No such device
[ 13.759849] hub 1-2:1.0: USB hub found
[ 13.767579] hub 1-2:1.0: 4 ports detected
/init: line 159: blkid: not found
/init: line 169: evtest: not found
[ 15.708217] Searching for partition GNUBEE-ROOT...
[ 15.717762] leds-gpio: probe of gpio-leds failed with error -16
/init: cd: line 10: can't cd to /sys/class/leds/gb-pc1:green:system: No such file or directory
findfs: unable to resolve 'PARTLABEL=GNUBEE-CRYPT-ROOT'
[ 18.563547] random: crng init done
findfs: unable to resolve 'LABEL=GNUBEE-ROOT'
/init: cd: line 10: can't cd to /sys/class/leds/gb-pc1:green:system: No such file or directory
/init: cd: line 10: can't cd to /sys/class/leds/gb-pc1:green:status: No such file or directory
BusyBox v1.30.1 (Debian 1:1.30.1-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ # lsblk
sh: lsblk: not found
/ # ip ad
1: lo: <LOOPBACK> mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast qlen 1000
link/ether 6a:0a:26:60:97:42 brd ff:ff:ff:ff:ff:ff
inet6 fe80::680a:26ff:fe60:9742/64 scope link
valid_lft forever preferred_lft forever
3: ethblack@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 90:50:5a:55:3a:50 brd ff:ff:ff:ff:ff:ff
4: ethblue@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 90:50:5a:55:3a:51 brd ff:ff:ff:ff:ff:ff
/ # config
Choose hostname (default gnubee.gnubee): pandora
## Hostname set to pandora
grep: /etc/shadow: No such file or directory
## root password changed
Configure network (ethblack) [s]tatic [d]hcp or [m]anual? s
IP address (192.168.1.10)? 172.16.100.110
Netmask (255.255.255.0)?
Gateway (172.16.100.1)?
DNS server (8.8.8.8)?
## Hostname set to pandora
grep: /etc/shadow: No such file or directory
## root password changed
## network configured - 172.16.100.110/24
./config: line 111: ntpdate: not found
## Hostname set to pandora
grep: /etc/shadow: No such file or directory
## root password changed
## network configured - 172.16.100.110/24
./config: line 111: ntpdate: not found
## Hostname set to pandora
grep: /etc/shadow: No such file or directory
## root password changed
## network configured - 172.16.100.110/24
./config: line 111: ntpdate: not found
grep: /etc/shadow: No such file or directory
## root password changed
## network configured - 172.16.100.110/24
./config: line 111: ntpdate: not found
## Hostname set to pandora
grep: /etc/shadow: No such file or directory
## root password changed
## network configured - 172.16.100.110/24
./config: line 111: ntpdate: not found
## Hostname set to pandora
grep: /etc/shadow: No such file or directory
## root password changed
## network configured - 172.16.100.110/24
./config: line 111: ntpdate: not found
<ctrl+c> to break ntp misconfiguration script .. as noted in other posting>
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=55 time=12.939 ms
64 bytes from 8.8.8.8: seq=1 ttl=55 time=14.233 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 12.939/13.586/14.233 ms
/ # cat /etc/resolv.conf
nameserver 8.8.8.8
/ # ping www.google.com
ping: bad address 'www.google.com'
/ #
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=55 time=12.939 ms
64 bytes from 8.8.8.8: seq=1 ttl=55 time=14.233 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 12.939/13.586/14.233 ms
/ # cat /etc/resolv.conf
nameserver 8.8.8.8
/ # ping www.google.com
ping: bad address 'www.google.com'
/ #
As such futher steps to load debian fail
/ # wget --no-check-certificate https://raw.githubusercontent.com/gnubee-git/Gnu
Bee_Docs/master/GB-PCx/scripts/jessie_3.10.14/debian-jessie-install
wget: bad address 'raw.githubusercontent.com'
/ #
Bee_Docs/master/GB-PCx/scripts/jessie_3.10.14/debian-jessie-install
wget: bad address 'raw.githubusercontent.com'
/ #
Brett Neumeier
Dec 11, 2021, 10:43:19 AM12/11/21
to penguinpages, GnuBee
Looks like your DNS is not configured correctly. You can work on getting that fixed, or you can add entries to /etc/hosts, or you can use IP addresses rather than host names.
(Apologies for bottom-quoting, I'm on my phone rather than a real computer)
--
You received this message because you are subscribed to the Google Groups "GnuBee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gnubee+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/155066be-d15b-4b9d-ab92-cbf89c9b0d2an%40googlegroups.com.
penguinpages
Dec 11, 2021, 11:07:10 AM12/11/21
to GnuBee
Thanks for response.
link/ether 90:50:5a:55:3a:50 brd ff:ff:ff:ff:ff:ff
4: ethblue@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 90:50:5a:55:3a:51 brd ff:ff:ff:ff:ff:ff
/ # wget --no-check-certificate https://raw.githubusercontent.com/gnubee-git/Gnu
Bee_Docs/master/GB-PCx/scripts/jessie_3.10.14/debian-jessie-install
wget: bad address 'raw.githubusercontent.com'
Ya.. kind of scratching head on what is going on here.
poked around a bit more...
/ # ip ad
1: lo: <LOOPBACK> mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast qlen 1000
1: lo: <LOOPBACK> mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast qlen 1000
link/ether 82:bb:1b:c8:9c:3a brd ff:ff:ff:ff:ff:ff
inet6 fe80::80bb:1bff:fec8:9c3a/64 scope link
valid_lft forever preferred_lft forever
3: ethblack@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
inet6 fe80::80bb:1bff:fec8:9c3a/64 scope link
valid_lft forever preferred_lft forever
3: ethblack@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
link/ether 90:50:5a:55:3a:50 brd ff:ff:ff:ff:ff:ff
inet 172.16.100.110/24 brd 172.16.100.255 scope global ethblack
valid_lft forever preferred_lft forever
inet6 fe80::9250:5aff:fe55:3a50/64 scope link
valid_lft forever preferred_lft forever
valid_lft forever preferred_lft forever
inet6 fe80::9250:5aff:fe55:3a50/64 scope link
valid_lft forever preferred_lft forever
4: ethblue@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 90:50:5a:55:3a:51 brd ff:ff:ff:ff:ff:ff
/ # cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.8.8
/ # nslookup
BusyBox v1.30.1 (Debian 1:1.30.1-4) multi-call binary.
Usage: nslookup [-type=QUERY_TYPE] [-debug] HOST [DNS_SERVER]
Query DNS about HOST
QUERY_TYPE: soa,ns,a,aaaa,cname,mx,txt,ptr,any
/ # nslookup www.google.com
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: www.google.com
Address: 108.177.122.147
Name: www.google.com
Address: 108.177.122.104
Name: www.google.com
Address: 108.177.122.103
Name: www.google.com
Address: 108.177.122.106
Name: www.google.com
Address: 108.177.122.99
Name: www.google.com
Address: 108.177.122.105
Non-authoritative answer:
Name: www.google.com
Address: 2607:f8b0:4002:c03::6a
Name: www.google.com
Address: 2607:f8b0:4002:c03::68
Name: www.google.com
Address: 2607:f8b0:4002:c03::63
Name: www.google.com
Address: 2607:f8b0:4002:c03::67
/ # nslookup www.yahoo.com
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
www.yahoo.com canonical name = new-fp-shed.wg1.b.yahoo.com
Name: new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:124:1507::f000
Name: new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:44:3507::8001
Name: new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:44:3507::8000
Name: new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:124:1507::f001
Non-authoritative answer:
www.yahoo.com canonical name = new-fp-shed.wg1.b.yahoo.com
Name: new-fp-shed.wg1.b.yahoo.com
Address: 74.6.231.21
Name: new-fp-shed.wg1.b.yahoo.com
Address: 74.6.143.25
Name: new-fp-shed.wg1.b.yahoo.com
Address: 74.6.143.26
Name: new-fp-shed.wg1.b.yahoo.com
Address: 74.6.231.20
BusyBox v1.30.1 (Debian 1:1.30.1-4) multi-call binary.
Usage: nslookup [-type=QUERY_TYPE] [-debug] HOST [DNS_SERVER]
Query DNS about HOST
QUERY_TYPE: soa,ns,a,aaaa,cname,mx,txt,ptr,any
/ # nslookup www.google.com
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: www.google.com
Address: 108.177.122.147
Name: www.google.com
Address: 108.177.122.104
Name: www.google.com
Address: 108.177.122.103
Name: www.google.com
Address: 108.177.122.106
Name: www.google.com
Address: 108.177.122.99
Name: www.google.com
Address: 108.177.122.105
Non-authoritative answer:
Name: www.google.com
Address: 2607:f8b0:4002:c03::6a
Name: www.google.com
Address: 2607:f8b0:4002:c03::68
Name: www.google.com
Address: 2607:f8b0:4002:c03::63
Name: www.google.com
Address: 2607:f8b0:4002:c03::67
/ # nslookup www.yahoo.com
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
www.yahoo.com canonical name = new-fp-shed.wg1.b.yahoo.com
Name: new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:124:1507::f000
Name: new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:44:3507::8001
Name: new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:44:3507::8000
Name: new-fp-shed.wg1.b.yahoo.com
Address: 2001:4998:124:1507::f001
Non-authoritative answer:
www.yahoo.com canonical name = new-fp-shed.wg1.b.yahoo.com
Name: new-fp-shed.wg1.b.yahoo.com
Address: 74.6.231.21
Name: new-fp-shed.wg1.b.yahoo.com
Address: 74.6.143.25
Name: new-fp-shed.wg1.b.yahoo.com
Address: 74.6.143.26
Name: new-fp-shed.wg1.b.yahoo.com
Address: 74.6.231.20
/ # wget --no-check-certificate https://raw.githubusercontent.com/gnubee-git/Gnu
Bee_Docs/master/GB-PCx/scripts/jessie_3.10.14/debian-jessie-install
wget: bad address 'raw.githubusercontent.com'
/ # nslookup raw.githubusercontent.com
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: raw.githubusercontent.com
Address: 185.199.108.133
Name: raw.githubusercontent.com
Address: 185.199.109.133
Name: raw.githubusercontent.com
Address: 185.199.110.133
Name: raw.githubusercontent.com
Address: 185.199.111.133
Non-authoritative answer:
/ # wget --no-check-certificate https://185.199.108.133/gnubee-git/GnuBee_Docs/
master/GB-PCx/scripts/jessie_3.10.14/debian-jessie-install
Connecting to 185.199.108.133 (185.199.108.133:443)
wget: server returned error: HTTP/1.1 404 Not Found
/ #
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: raw.githubusercontent.com
Address: 185.199.108.133
Name: raw.githubusercontent.com
Address: 185.199.109.133
Name: raw.githubusercontent.com
Address: 185.199.110.133
Name: raw.githubusercontent.com
Address: 185.199.111.133
Non-authoritative answer:
/ # wget --no-check-certificate https://185.199.108.133/gnubee-git/GnuBee_Docs/
master/GB-PCx/scripts/jessie_3.10.14/debian-jessie-install
Connecting to 185.199.108.133 (185.199.108.133:443)
wget: server returned error: HTTP/1.1 404 Not Found
/ #
Kind of as expected. HTTP server expects to parse name string for site details... still working on it.. but this seems a bit odd
penguinpages
Dec 11, 2021, 11:10:49 AM12/11/21
to GnuBee
Well.. it is ignoring /etc/hosts
/ # cat /etc/hosts
185.199.108.133 raw.githubusercontent.com
172.16.100.22 ados.penguinpages.local ados
/ # ping ados.penguinpages.local
ping: bad address 'ados.penguinpages.local'
/ # ping raw.githubusercontent.com
ping: bad address 'raw.githubusercontent.com'
185.199.108.133 raw.githubusercontent.com
172.16.100.22 ados.penguinpages.local ados
/ # ping ados.penguinpages.local
ping: bad address 'ados.penguinpages.local'
/ # ping raw.githubusercontent.com
ping: bad address 'raw.githubusercontent.com'
So that hack around option is out
Neil Brown
Dec 21, 2021, 7:50:47 PM12/21/21
to GnuBee
I"m sorry the 5.10 firmware isn't working for you. I guess I didn't test it very thoroughly. The messages about /etc/shadow and ntpdate clearly pointing to something wrong with the initramfs in the firmware.
I'd suggest trying an earlier kernel - 5.7.2 or even 5.6.16.
I hope to find time this (Australian) summer to get 5.15 working, and then I'll do a proper test install. But time has been in short supply lately.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages