On Saturday 03 February 2018 23:37:46 Gene Heskett wrote:
> On Saturday 03 February 2018 21:04:40 Paul Wise wrote:
> > On Sun, Feb 4, 2018 at 12:46 AM, Gene Heskett wrote:
> > > I know you cannot remove a package with it, because its
> > > interpretation of dependencies will leave you with an unbootable,
> > > destroyed system. Its done that to me several times already.
> > I remove packages with aptitude all the time and have no problem
> > with that. You can remove packages with apt if aptitude isn't
> > working for you.
> > > So when do we get a default, just works, does _only_ what you ask
> > > it to, text/ncurses based package manager with a bare bones arm64
> > > install? Something you can actually build a working system with?
> > For me, aptitude is exactly that, except I have no arm64 hardware,
> > but aptitude isn't any different on different architectures, except
> > it is of course slower on slower disks and CPUs.
> > I think you might be better suited by a few things:
> > Choose one environment instead of two.
> > Use a light-weight WM like openbox instead of a desktop.
> > Turn off recommends in your apt configuration to reduce the size of
> > the image.
> > /etc/apt/apt.conf.d/99recommends:
> > APT::Install-Recommends "false";
> > Build the rootfs on a fast SSD/HD (or tmpfs if you have enough RAM)
> > with a fast CPU. One way would be on amd64 using qemu-debootstrap
> > from qemu-user-static and then write the completed rootfs to your SD
> > card.
> > Start with the --variant=minbase option for debootstrap to ensure
> > only the minimal is initially installed.
> > > While I am up on my soapbox about this, that set of html docs on
> > > aptitude someone pointed me at, is that available in a printable
> > > pdf? Link plz if it is.
> > Doesn't look like it. You could file a bug against aptitude-doc-en.
> > https://www.debian.org/doc/user-manuals#aptitude
> > https://packages.debian.org/sid/all/aptitude-doc-en/filelist
> I am already 83, I'd like to have a usable copy while I'm still
> regularly sucking air...
> I have another 64GB card prepared.
Minimal stretch image not a jessie image
> I'll go put it in, fix the
> networking, and use apt to pull in what I want, one package and its
> dependencies at a time.
> Except I had to let gparted "fix" some bad partition table entries.
> then had to haul it back for yet another session to get the rock64 to
> recognize it as a 59GB card.
> Got that fixed, but now I've a mistake someplace in the network setup
> so while its getting the correct address, its is not putting a UG
> entry in the route -n output.
> /etc/resolv.conf is a real file. contains:
> domain foo.bar
> nameserver 192.168.xx.1
> search hosts nameserver
> /etc/network/interfaces.d/eth0 contains:
> auto eth0
> iface eth0 inet static
> address 192.168.xx.2/24
> gateway 192.168.xx.1
> ifoot@rock64:~# ifquery eth0
> address: 192.168.xx.2
> netmask: 255.255.255.0
> gateway: 192.168.xx.1
> broadcast: 192.168.xx.255
> query eth0 returns the correct data, including the gateway address
> but a route -n has no UG line.
> oot@rock64:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 202 0
> 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 202 0
> 0 eth0 192.168.xx.0 0.0.0.0 255.255.255.0 U 0 0
> 0 eth0
> I would also add that this exact same configuration Just Works on an
> sdcard with a bare bones jessie image on it. Studying the man for
On another jessie machine, no man pages installed in the stretch image
> I have not been able to get past an error with a line that
> should add a gateway address. Example, probably incorrect:
> root@rock64:~# route add -net GW 192.168.71.1 eth0
> GW: No address associated with name
> Clues? Or is route broken?
Forgot to send this before sleeping, up again at 4am, I found this last
line, added to /etc/network/interfaces.d/eth0, made it work.
root@rock64:~# cat /etc/network/interfaces.d/eth0
iface eth0 inet static
up route add default gw 192.168.nn.1
So thats fixed. Presumably the "gateway" line could go away, but why did
it not work? seems like the better question.
I checked sha512sums on /sbin/route between the jessie and stretch, both
for arm64 as I had rsync'ed a copy of the previous jessie to spinning
rust, identical. So the malfunction is someplace else. Both were about
20k bigger than the /sbin/route on a pi running jessie.
Thanks everybody with ideas.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>