Re: aptitude is blowing up again.

[Philip Hands]

On Sun, 04 Feb 2018, Gene Heskett  wrote:
> On Saturday 03 February 2018 23:27:11 Paul Wise wrote:
>
>> On Sun, Feb 4, 2018 at 10:14 AM, Gene Heskett wrote:
>> > 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.
>>
>> > 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.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: aptitude is blowing up again.

[Wookey]

On 2018-02-03 11:46 -0500, Gene Heskett wrote:
> 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.

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

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

> 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
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Utilite Pro

[Gert Wollny]

Am Samstag, den 03.02.2018, 10:05 -0500 schrieb Scott:
> 
> 
> [0.242990] Unpacking initramfs...
> [0.243373] Initramfs unpacking failed: read error
> 
> Can share entire boot.scr, but thinking it could be bootargs or
> memory  addresses.  Fairly certain ramdisk is last file loaded, so
> ${filesize}  should work with bootz.
> 
> bootargs "root=/dev/ram0 rw console=ttymxc3,115200n8 rootwait
> panic=10"
> 
> setenv loadaddr 0x1080
> setenv fdtaddr 0x1500
> setenv fdt_high 0x
> setenv bootm_low 0x1500
> setenv ramdisk_addr 0x1200
> setenv bootm_size 0x2000
> setenv kernel_file vmlinuz
> setenv ramdisk_file initrd.gz
> 
> bootz ${loadaddr} ${ramdisk_addr}:${filesize} ${fdtaddr};
> 
> I get the same results with debian imx6q-utilite-pro.dtb and 
> imx6q-cm-fx6.dtb, as well as Compulab imx6q-sbc-fx6.dtb.

There is another boot partition available in 

  images/kernel-update.tar.bz2 

and this I got to boot. It doesn't have a ramdisk. Currently, I use a
Ubuntu 16.04 userspace with a patched glibc to accept the old kernel
3.0* that was there before though, so for some reason NFS is not
working and NAT seems to be disabled in the kernel (have to
investigate). 


> Other notes:
> 
> boot.scr for debian installer
> 
> http://ftp.nl.debian.org/debian/dists/stretch/main/installer-armhf/cu
> rrent/images/hd-media/
> 
> reports
> 
> Non-mainline u-boot or old-style mainline u-boot detected.
> This boot script uses the unified bootcmd handling of mainline
> u-boot >=v2014.10, which is not available on your system.
> 
> Compulab has made Stretch images available last January.  I used
> this  boot.scr as starting point.

There is a v2015 uboot package available 

http://www.compulab.co.il/utilite-computer/wiki/index.php/Utilite_U-
Boot_Update


Best, 
Gert 

no gateway is set, was Re: aptitude is blowing up again.

[Gene Heskett]

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 RefUse
> Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 2020  
>  0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 2020
>0 eth0 192.168.xx.00.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

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

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

Re: aptitude is blowing up again.

[Gene Heskett]

On Sunday 04 February 2018 05:23:56 Wookey wrote:

> On 2018-02-03 11:46 -0500, Gene Heskett wrote:
> > 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.
>
> > 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.  

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

Re: Utilite Pro

[Scott Tablett]

On 2/4/2018 5:46 AM, Gert Wollny wrote:

There is another boot partition available in
   images/kernel-update.tar.bz2

and this I got to boot. It doesn't have a ramdisk. Currently, I use a
Ubuntu 16.04 userspace with a patched glibc to accept the old kernel
3.0* that was there before though, so for some reason NFS is not
working and NAT seems to be disabled in the kernel (have to
investigate).

Thanks Gert,

You give a good idea having root on sdcard versus ramdisk.  I am not 
seeing kernel-update.tar.bz2 in debian installer images folder. Maybe 
you are referring to Ubuntu.


ftp://ftp.ca.debian.org/debian/dists/testing/main/installer-armhf/current/images/




Other notes:

boot.scr for debian installer

http://ftp.nl.debian.org/debian/dists/stretch/main/installer-armhf/cu
rrent/images/hd-media/

reports

Non-mainline u-boot or old-style mainline u-boot detected.
This boot script uses the unified bootcmd handling of mainline
u-boot >=v2014.10, which is not available on your system.

Compulab has made Stretch images available last January.  I used
this  boot.scr as starting point.

There is a v2015 uboot package available

http://www.compulab.co.il/utilite-computer/wiki/index.php/Utilite_U-
Boot_Update

Thanks for pointing out update.  I updated on-board SPI flash following 
the link you provided.

Debian installer boot.scr results in same message.
The Debian boot.scr checks for ${boot_targets} .  This is not set in 
Compulab u-boot update.

Re: Mirabox kernel help needed

[Leigh Brown]

Hi Dale,

On 2018-02-02 16:23, amon wrote:

Okay, I hadn't been thinking in those terms because in my mind
I already had the sdcard 'allocated'. That is useful. Bricking
GlobalScale units is definitely a thing... I managed to do it
to one of there Guru boxes back in 2012. Never had time to
fix it; at those prices it was cheaper to bin it than have them
pay me to figure it out!

As to the development, I can do both. I have a full set of the
packages for the release on the Miraboxes (7.1) ... it is an old
release but they have stayed with it for years and but for the
kernel it serves my purposes. I have one of the test units
designated as the development system for my own debian packages
anyway and I've already got gcc and all of the debian helper
package tool chain on it.

Also, I have several 256 GB USB 3.0 sticks laying around my lab
bench, so no problem.

I am really glad to hear that cross compilers have been
simplified. Walking 10 miles to school in deep snow, up hill
both ways, is best left in the past.

I'm hoping to come out of this with a simple, replicable
install sequence using the newly built kernel and module
set... I will have to replicate this on at least 4 other
units. It would also be nice if I can breath life into 4
old units I have and be able to describe the process to a
couple of folks who work with me remotely on occasion so
they can upgrade as well.


I have had a little time over the weekend so I have created a
(lightly tested) procedure to build an SD Card image from a
system running 32-bit or 64-bit Debian (Stretch) on an Intel PC.

https://www.solinno.co.uk/public/mirabox/debian_cross_compile.html

Please try it out and let me know if anything isn't clear or
you have any issues.  It should be simple to extend the procedure
to flash the kernel and initrd onto the NAND and transfer the root
filesystem from the SD Card to the on-board UBIFS filesystem.  I'll
do that next time I have some free time.

Regards,

Leigh.

Re: Utilite Pro

[Vagrant Cascadian]

On 2018-01-31, Scott wrote:
> but would like to user installer via SD-card-image
>
> http://ftp.nl.debian.org/debian/dists/stretch/main/installer-armhf/current/images/hd-media/SD-card-images/
...
> Are the Stretch u-boot images based off v2017.05 
> 
> https://anonscm.debian.org/cgit/collab-maint/u-boot.git/

Stretch is based off of u-boot 2016.11, the upstream version available
at the time stretch froze.

I don't see any mention of utilite models in upstream u-boot, so it's
not possible to provide pre-built bootable debian-installer images.

If you have a vendor-provided u-boot, you might be able to get it to
work with the debian-installer images, possibly manually loading the
kernel+initrd+dtb from the u-boot prompt and booting. You'll likely need
a serial console connected to troubleshoot.

Good luck!


live well,
  vagrant

Re: su -s not working on TS-109II?

[[ftp83plus]]

Hi, thanks for the tip, but sudo is not installed, and I can’t install anything 
since apt-get requires root access, or at least sudo. 

Maybe I left the configuration half-finished when I used the serial console? I 
don’t recall this part.


> El 4 feb 2018, a las 20:16, gilberto dos santos alves  
> escribió:
> 
> hi. have you used
> sudo passwd root
>  (choose one new pass for root) 
> (confirm new rott pass)
> 
> su -
> (inform new root pass from previus step)
> 
> now your prompt is using # and you are root
> 
> Em 03/02/2018 05:41, mailto:ges...@ftp83plus.net>> 
> escreveu:
> Indeed there are only a handful of passwords I temporarily use for systems 
> that aren't open to the Internet. Tried all of them, but it didn't succeed.
> 
> I clearly recall that it worked using the serial console, though.
> 
> Enviado desde mi iPhone
> 
> > El 3 feb 2018, a las 1:02, Martin Michlmayr  > > escribió:
> >
> > * [ftp83plus] mailto:ges...@ftp83plus.net>> 
> > [2018-02-02 21:20]:
> >> but command su -s always denies me permission when I enter password for 
> >> user.
> >
> > Maybe I misread your email, but with "su" you have to provide the root
> > password, not the password for your user.
> >
> > --
> > Martin Michlmayr
> > http://www.cyrius.com/ 
> >
> 

Re: Mirabox kernel help needed

[amon]

Got it and printed a copy for annotation when I get to the
lab tomorrow. Thanks much.

--
+---+
|   Dale Amon  Immortal Data|
|   CEO Midland International Air and Space Port|
| a...@vnl.com   "Data Systems for Deep Space and Time" |
+---+