Re: aptitude is blowing up again.
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
> > 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.
> 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.
I am already 83, I'd like to have a usable copy while I'm still regularly
I have another 64GB card prepared. I'll go put it in, fix the networking,
and use apt to pull in what I want, one package and its dependencies at
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:
search hosts nameserver
iface eth0 inet static
ifoot@rock64:~# ifquery eth0
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 route,
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?
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>