aptitude is blowing up again.

[Gene Heskett]

greetings all;

I very carefully selected docs, x11, kde and xfce to be installed on
this rock64. That was something over 2000 packages when I hit the g.
There was a bare jessie image, a little under 3.5 GB on the sdcard at
that point, around 20:00 last night. 32GB sdcard. aptitude just keeps
selecting previously unselected stuff, that sdcard is now at 80%,
working extremely slowly and apparently nowhere near done. I suspect it
will die, out of disk space, perhaps next Wednesday at 3 AM, if I don't
unplug it first.

***@rock64:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mmcblk1p7 30299144 23181512 5846304 80% /

htop, on a separate login screen says its not any sort of resource
constrained and is not using any swap. All of its ncurses gfx have
disappeared, and I am looking at dpkg output in my login shell as it
seems bound and determined to install the whole debian arm64 repo for
jessie. And it has not yet installed synaptic-pkexec.

So how _do_ you control this application?

I'm at this point, ready to re-write that image to a 64GB sdcard, and
spend days using apt to pull stuff I need in one package at a time. 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.

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?

Sigh.

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.

Thanks.

[Paul Wise]

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

[Gene Heskett]

Post by Paul Wise

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.
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.
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. 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

***@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.
***@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:
***@rock64:~# route add -net GW 192.168.71.1 eth0
GW: No address associated with name

Clues? Or is route broken?

[Gene Heskett]

Post by Gene Heskett

Post by Paul Wise

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.
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.
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

Post by Gene Heskett
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.
domain foo.bar
nameserver 192.168.xx.1
search hosts nameserver
auto eth0
iface eth0 inet static
address 192.168.xx.2/24
gateway 192.168.xx.1
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.
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,

On another jessie machine, no man pages installed in the stretch image

Post by Gene Heskett
I have not been able to get past an error with a line that
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.

***@rock64:~# cat /etc/network/interfaces.d/eth0
auto eth0
iface eth0 inet static
address 192.168.nn.2
netmask 255.255.255.0
gateway 192.168.nn.1
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.

[Gene Heskett]

Post by Gene Heskett
greetings all;
I very carefully selected docs, x11, kde and xfce to be installed on
this rock64. That was something over 2000 packages when I hit the g.
There was a bare jessie image, a little under 3.5 GB on the sdcard at
that point, around 20:00 last night. 32GB sdcard. aptitude just keeps
selecting previously unselected stuff, that sdcard is now at 80%,
working extremely slowly and apparently nowhere near done. I suspect
it will die, out of disk space, perhaps next Wednesday at 3 AM, if I
don't unplug it first.
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mmcblk1p7 30299144 23181512 5846304 80% /
htop, on a separate login screen says its not any sort of resource
constrained and is not using any swap. All of its ncurses gfx have
disappeared, and I am looking at dpkg output in my login shell as it
seems bound and determined to install the whole debian arm64 repo for
jessie. And it has not yet installed synaptic-pkexec.
So how _do_ you control this application?
I'm at this point, ready to re-write that image to a 64GB sdcard, and
spend days using apt to pull stuff I need in one package at a time. 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.
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?
Sigh.
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.
Thanks.

excedrin headache #9171

It turns that I am not supposed to be running aptitude as root. I can
live with that, but my sudo password doesn't give me root permissions
when its time to actually do something.

WTF?

I've another sdcard with a fresh minimal jessie on it, a 64GB, maybe that
will give me a little room to play. But I'll damn sure figure out a way
to do it without aptitude.

[Paul Wise]

Post by Gene Heskett
It turns that I am not supposed to be running aptitude as root.

If you want it to make changes to the system you must run it as root.

Post by Gene Heskett
but my sudo password doesn't give me root permissions
when its time to actually do something.

That seems quite unlikely, what error message does it give?

[Gene Heskett]

Post by Paul Wise

Post by Gene Heskett
It turns that I am not supposed to be running aptitude as root.

If you want it to make changes to the system you must run it as root.

Post by Gene Heskett
but my sudo password doesn't give me root permissions
when its time to actually do something.

That seems quite unlikely, what error message does it give?

Says its not root's pw.

But I can sudo -i and run it.

[Philip Hands]

Post by Gene Heskett

Post by Paul Wise

Post by Gene Heskett
It turns that I am not supposed to be running aptitude as root.

If you want it to make changes to the system you must run it as root.

Post by Gene Heskett
but my sudo password doesn't give me root permissions
when its time to actually do something.

That seems quite unlikely, what error message does it give?

Says its not root's pw.

It seems that it's running su not sudo, and hence is expecting root's
password, rather than your password.

As someone who uses apt (or apt-get on older systems) running as root,
I'm afraid I've no idea what might entice aptitude to choose su vs. sudo
in this case, sorry.

Running aptitude as root from the start is fine though.

Cheers, Phil.

[Wookey]

Post by Gene Heskett
greetings all;
I very carefully selected docs, x11, kde and xfce to be installed on
this rock64. That was something over 2000 packages when I hit the g.

Seems a lot, but X and two desktops is a lot of stuff. Using
--no-install-recommends is one way to install way less stuff. (In the
GUI untick "Install recommended packages automatically " under
'Options'). I always do this for build-dependencies. Possibly not such
a good idea for a desktop but it should work. Why are you installing
two desktops if you don't want 'too much' stuff?

I just tried using a bare, current unstable chroot. Installing x11,
kde, and xfce (sudo aptitude install xserver-xorg xfce4
task-kde-desktop) is 1792 packages 3907 MB unpacked). Without
recommends (sudo aptitude --without-recommends install xserver-xorg
xfce4 task-kde-desktop) it's 1005 packages, 1993 MB unpacked

Doing it in the curses interface gets the same results, showing me that
xserver-xorg is +67MB,
xfc4 +1682MB,
task-kde-desktop +3810MB,

so X is much lighter wieght than a desktop. xfce4 desktop is half the
weight of a kde desktop.

Now I did just check that on this x86 machine, but it really shouldn't
be materially different on arm64.

Post by Gene Heskett
So how _do_ you control this application?

Aptitude is marvellous. I'm not sure why you are having trouble with it.

It has a nice interface that make exploring dependencies very easy -
you can add and remove stuff easily, and it's good at doing tricky
resolving. It certainly used to be a lot better than apt in this
regard, although I think they are nearly equivalent again these days.

And you can choose whether to use cli or curses.

Post by Gene Heskett
I'm at this point, ready to re-write that image to a 64GB sdcard, and
spend days using apt to pull stuff I need in one package at a time. 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.

Nonsense. If you want to report bugs you are going to need to be
specific, about 'before' status, and 'after' status. If aptitude is
really messing up arm64 systems just because you asked to remove
packages then that's not good. But without enough info to reproduce
nothing much can be done.

Post by Gene Heskett
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?

I use aptitude all the time, for many years, on arm and x86. It has
_very_ rarely screwed up. It's actually quite good at _unscrewing_ a
machine with a messed-up mixed set of packages.

Are you mixing repositories (like stable and unstable?). Be very
careful if doing that. An incredibly useful tip is to change the default aptitude display to include the suite name:
change (in 'preferences') 'display format' from:
%c%a%M%S %p %Z %v %V
to
%c%a%M%S %p %Z %t %v %V

(IMHO this should be the default for everyone).

Wookey

[Gene Heskett]

Post by Wookey

Post by Gene Heskett
greetings all;
I very carefully selected docs, x11, kde and xfce to be installed
on this rock64. That was something over 2000 packages when I hit the
g.

Seems a lot, but X and two desktops is a lot of stuff. Using
--no-install-recommends is one way to install way less stuff. (In the
GUI untick "Install recommended packages automatically " under
'Options'). I always do this for build-dependencies. Possibly not such
a good idea for a desktop but it should work. Why are you installing
two desktops if you don't want 'too much' stuff?
I just tried using a bare, current unstable chroot. Installing x11,
kde, and xfce (sudo aptitude install xserver-xorg xfce4
task-kde-desktop) is 1792 packages 3907 MB unpacked). Without
recommends (sudo aptitude --without-recommends install xserver-xorg
xfce4 task-kde-desktop) it's 1005 packages, 1993 MB unpacked
Doing it in the curses interface gets the same results, showing me
that xserver-xorg is +67MB,
xfc4 +1682MB,
task-kde-desktop +3810MB,
so X is much lighter wieght than a desktop. xfce4 desktop is half the
weight of a kde desktop.
Now I did just check that on this x86 machine, but it really shouldn't
be materially different on arm64.

Post by Gene Heskett
So how _do_ you control this application?

Aptitude is marvellous. I'm not sure why you are having trouble with it.

Because the man page sucks dead toads thru soda straws? Most of us are
too used to a decent gui. The man page spends quite close to zero
characters describing what pressing key x does. Its extremely easy to
get lost if you don't have a decent docs from the website visible on
another workspace screen, IF you have x and some sort of a desktop that
allows multiple work spaces. So I am walking back and forth from where
this is peeking out from under one corner of an old dell, and typing on
a keyboard thats resting on a tablesaw, to one of my wheezy machines
where those docs are displayed. All that putzing around is quite
distracting to an old fart having enough troubles with his short term
memory.

Oh and top that off with the fact that at that stage of the install, not
even the man utility is available. That of course is not debian's fault,
sorry if thats what it sounds like, it isn't. But it is what it is.
Have apt install task.xfce brought in the man pages and man so that is
NOW available, but was not yesterday.

At this point, I have 3 major projects to complete before I can test
this.

1. build a realtime kernel, and get it installed on a u-boot system.
Buil;ding the kernel, on the rock64 is a piece of cake, getting it
installed on a u-boot system is not.

2. build the latest git clone of linuxcnc-master.
No problem doing that mid october last year.

3. build the interface hardware to connect a mesa 7i90HD interface card
to the rock64's spi, hopefully using the same gpio connector adapter
thats used on the pi's for this. As cables go, its source terminated and
about 1" long because its a 50 megahertz circuit. Connector orientations
make me mount the pi upside down on standoffs, with a video card fan
under it. NBD.

Looking at the kernels driver src for the rock64, I see that it claims up
to 50 megabaud so there's a chance it might work, but this spi driver is
missing the ability to write at one speed, while reading the responses
at a different, slower speed. And this is a case where every nanoscond
counts.

So there are a lot of "if's" between now and moving machinery in real
time with it, which the pi is doing very well.

The pi's problem is hardware architecture, and results in keyboard/mouse
events being thrown away, something I don't believe the rock64 will do.

Post by Wookey
It has a nice interface that make exploring dependencies very easy -
you can add and remove stuff easily, and it's good at doing tricky
resolving. It certainly used to be a lot better than apt in this
regard, although I think they are nearly equivalent again these days.
And you can choose whether to use cli or curses.

Post by Gene Heskett
I'm at this point, ready to re-write that image to a 64GB sdcard,
and spend days using apt to pull stuff I need in one package at a
time. 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.

Nonsense. If you want to report bugs you are going to need to be
specific, about 'before' status, and 'after' status. If aptitude is
really messing up arm64 systems just because you asked to remove
packages then that's not good. But without enough info to reproduce
nothing much can be done.

After watching it fill up a 32gig pny card, killing it with htop when
there was about 30k of the card left, it did not respond to several
ctl-c's, it kept very good records and wanted to finish the job when I
restarted it. But I wanted to remove a few gig's of stuff I'll never use
first. That was when I powered it down and put a minimal stretch image
on a 64gig card, a samsung, except I've wasted a day getting it to
assign a gateway to the network. Something just had to be changed.

Reason? I dunno.

Post by Wookey

Post by Gene Heskett
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?

I use aptitude all the time, for many years, on arm and x86. It has
_very_ rarely screwed up. It's actually quite good at _unscrewing_ a
machine with a messed-up mixed set of packages.
Are you mixing repositories (like stable and unstable?).

No. /etc/apt/sources is virgin. It may grow an entry to the
buildbot.linuxcnc.org eventually, but it can build the git pull too.

Post by Wookey
Be very
careful if doing that. An incredibly useful tip is to change the
default aptitude display to include the suite name: change (in
%c%a%M%S %p %Z %v %V
to
%c%a%M%S %p %Z %t %v %V

I'm not even sure how to access that. As stated, the man page sucks. So
I've no clue how to access that. And as root, or the user?

msg marked FFR.

Post by Wookey
(IMHO this should be the default for everyone).
Wookey

Thank you Wookey.