Re: my raspbian jessie repo seems to have been moved to packagecloud.io
On 04/09/18 01:00, Gene Heskett wrote: Greetings all; So how do I install the new key for B62D900077D1B979 Gene, that's not remotely a Debian problem. Raspbian's a derivative of Debian but things like the organisation of their package repository are completely distinct, so while some of the more general issues which might affect multiple Debian derivatives (e.g. both Raspbian and the OS on your Rock board) might be relevant here I'm afraid that one isn't. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Running Pure Debian on the Raspberry Pi 3B+?
On 8/14/18, Rogério Brito wrote: I am thinking of getting a Raspberry Pi 3B+ and, from what I read, it is mostly supported by the upstream Linux kernel, but I still have doubts about what I may be losing or not, compared to Raspbian. >From what I read, there are some binary blobs needed for the video to work (and I would like to use it with Kodi, to play some videos and to, perhaps, act as a NAS or a place where I can use to save some files via NFS when a USB HD is attached to it). Apologies for missing the original message which for some reason got marked as spam/malware. We're running a number of RPi3s here with the "Jessie" build done by Collabora, which relies on the Raspbian kernel and loader (hence also any proprietary binaries), originally because KDE didn't play nicely with Raspbian. I've also looked briefly at somebody's 64-bit port. My suggestion would be to stick with Raspbian unless you have a very good reason to explore alternatives. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: RockChip (and possibly others) broken static IP
On 27/07/18 21:15, Gene Heskett wrote: On Friday 27 July 2018 12:29:34 Mark Morgan Lloyd wrote: I found the 8.8.8.8 in /etc/resolvconf/resolvconf.d/head and changed it to point at the router, and rebooted since a service networking restart hung and never came back from this machines login. For a local router you're probably better using a gateway in /e/n/interfaces and then removing anything hardwired in the head or tail file. Pulled the sd card from the pi and dd'd it to a file that was just short of 32GB, took about an hour, but its writing slower and is still blinking away at putting that file on a 64GB sd card for a backup after nearly 2 hours. With 64GB, and I don't care if it never gets resized as that 32GB is way more than enough to hold this install. You can speed it up by using e.g. bs=128M so that dd is handling larger chunks. Keep a note with the card so that you know you that you don't have to back the whole 64Gb up. And it sharpened a table saw blade far sharper than anything I can buy, using a dremel at about half speed, driving the cable wand bolted to the mini-mills head casting which had a 1.5" diameter diamond disk mounted. Neat but I'm afraid very much off-topic. What appears to be happening is that both dhcpcd and NetworkManager are being started by systemd, and while NetworkManager can be relied on to leave interfaces mentioned in /e/n/interfaces alone it appears that dhcpcd is nowhere near as well-behaved. I'm unsure about the side-effects of this, but for the sake of getting things to a testable state dhcpcd can be disabled using something like # systemctl stop dhcpcd # systemctl disable dhcpcd # systemctl mask dhcpcd That restores things to the "classic Debian" state where /e/n/interfaces is obeyed, but where NetworkManager will try to handle any interfaces that are not explicitly listed (in particular WiFi). If one doesn't want NetworkManager, then it can be disabled in a similar fashion. I'd suggest not trying to uninstall it. I've just been looking at removing dhcpcd5 which appears to be redundant and the cause of the original gateway problem. However on the TinkerBoard doing that also removes tinker-config which would be undesirable. It's possible to configure dhcpcd to ignore certain types of interface, but I can't see a way to tell it not to try to preempt /e/n/interfaces. However this is by no means the first time that I've found inconsistencies in this area. Noted JP's previous comments that systemd should be allowed to handle much of this stuff, but e/n/interfaces concentrates most of the interface configuration in one place and as long as it's installed by default it's reasonable to expect it, and its extensions, to work. And before it's deprecated and removed I trust that somebody will document and test its replacement, and test that all combinations of the replacement extensions interwork correctly. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
RockChip (and possibly others) broken static IP
A few days ago Gene Heskett was complaining that his RockChip-based board was refusing to pick up a gateway address defined statically in /e/n/interfaces or /e/n/interfaces.d. I just thought I'd confirm that I can also see that on a (RockChip-based) Tinkerboard, although I've not seen it on a Raspberry Pi or a PC. My suspicion is that the boards that Gene and I are using have a "common ancestor" rather closer than the Debian masters, and that this has introduced questionable configuration. What appears to be happening is that both dhcpcd and NetworkManager are being started by systemd, and while NetworkManager can be relied on to leave interfaces mentioned in /e/n/interfaces alone it appears that dhcpcd is nowhere near as well-behaved. I'm unsure about the side-effects of this, but for the sake of getting things to a testable state dhcpcd can be disabled using something like # systemctl stop dhcpcd # systemctl disable dhcpcd # systemctl mask dhcpcd That restores things to the "classic Debian" state where /e/n/interfaces is obeyed, but where NetworkManager will try to handle any interfaces that are not explicitly listed (in particular WiFi). If one doesn't want NetworkManager, then it can be disabled in a similar fashion. I'd suggest not trying to uninstall it. It's possible to configure dhcpcd to ignore certain types of interface, but I can't see a way to tell it not to try to preempt /e/n/interfaces. However this is by no means the first time that I've found inconsistencies in this area. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On 27/07/18 01:15, Brian Sammon wrote: On Wed, 25 Jul 2018 16:57:09 -0400 Gene Heskett wrote: The only possible mention is at <https://forum.odroid.com/viewtopic.php?f=138&t=20593> Which links to https://fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html which is particularly interesting. Also, it's my understanding that this problem exists with nearly all of these pocket-computer/fruit-pi devices to some degree or other -- to the point that it's a shorter list of the devices that don't have this problem than a list of the devices that do. (Anyone know of such a list?) I think the real question is whether to countenance something that has a boot loader in Flash which can be (intentionally or otherwise) overwritten (link here is interesting since it gives a memory layout http://odroid.com/dokuwiki/doku.php?id=en:c2_partition_table ) or whether to prefer something in ROM (which is what the RPi has). The robustness of the ROM approach has a lot going for it, but it can cause a Hell of a problem if either it contains a hardware-initialisation bug (which might be the cause of some issues I'm currently exploring) or if it leaves the hardware in an operating state which the device's owner considers unacceptable (e.g. one that requires a signed kernel). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On 26/07/18 17:45, Gene Heskett wrote: On Thursday 26 July 2018 12:51:07 Mark Morgan Lloyd wrote: Wouldn't the file, if put on /media/slash, it seems dd would include /media/slash in that file, and the result even if it didn't get into a recursion forever loop, would still be around 10GB bigger than media//slash, and it already has some stuff on it: I was assuming that you weren't trying to dd to something on the same physical device... which would be highly inadvisable if not impossible since you need to put what you're copying from into a quiescent state (i.e. single user or as Adam pointed out fsfreeze. Not from-to the same device, / is a 32Gb u-sd card its currently booting from, and /media/slash is /dev/sda3, hooked up by a usb-3<->sata adapter plugged into a usb-2 port. But the /media mount point is in the u-sd file structure. Would dd follow that into the files that are there on the SSD? No, dd is copying the device not the files it contains, so is completely oblivious of mounts etc. There is supposed to be a flag that can make the pi-3b boot from an attached hard drive, but I have never had the command to flip it, work always a permissions error or something. Early pi's don't have it? Recap: RPi3 has a 32Kb ROM (not Flash) containing boot code. Depending on what it reads from one-time programmable storage, it either boots from SDCard, or it also tries to look at USB mass-storage devices or LAN. External boot is disabled by default, and on the original RPi3 is still a bit flaky... my desktop RPi boots from a Maxstor disc via a Newlink hub but I've had limited success with other combinations. The OTP may also be set so that the boot code in ROM reads some GPIO pins to determine whence to boot, but I've not played with that. -8<- [Add] program_usb_boot_mode=1 to the end of /boot/config.txt. Reboot the Raspberry Pi with sudo reboot. Once the client Raspberry Pi has rebooted, check that the OTP has been programmed with: $ vcgencmd otp_dump | grep 17: 17:302a Ensure the output 0x302a is correct. The client configuration is almost done. The final thing to do is to remove the program_usb_boot_mode line from config.txt (make sure there is no blank line at the end). ->8- Plus plenty of other stuff if you Google. So either get another temporary device and connect it via USB, or use dd+netpipes to copy the device onto a different system over the LAN. or sshfs. I don't currently have it setup so root can use it though, just me is all. No. dd DOES NOT copy the content of a filesystem, it copies the entire filesystem /or/ the entire partition /or/ the entire device. I need dd like to preserve the file addresses in /boot as I've read they are expected to be at fixed addresses with this boot method. There's usually something that can't easily be moved, unless there's a loader in ROM with enough smarts to be able to drive a FAT (etc.) filesystem. Which I don't believe the pi-3b has. It does, see above. So I'd best pull that sd card, put it in a reader and dd it to a file, then dd that file back to a 64 Gb sd just to make a backup copy? I'll need a few more 64Gb's just to have working room. For removable devices... yes, that's the easiest way. However (a) this might surprise you but keeping an image of an SDCard is an entirely adequate backup and (b) when you do write one back to a card note my earlier comments about possibly needing to reduce its size slightly since you can't rely on all "64Gb" cards having exactly the same number of sectors. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On 26/07/18 16:15, Gene Heskett wrote: On Thursday 26 July 2018 03:06:31 Mark Morgan Lloyd wrote: On 25/07/18 21:30, Gene Heskett wrote: On Wednesday 25 July 2018 16:15:03 Mark Morgan Lloyd wrote: There are still ways of working round that sort of problem. For example, you can copy an entire device using dd to capture boot segments and partition layout, inspect and recreate the filesystems using mkfs, then use [something] to copy files one at a time into the new filesystems taking care that some bootloaders need a wakeup call when a file moves. As far as "something" is concerned: dd: Sector-by-sector copy between devices and files. tar: Good ol' archiver, with directory-exclude etc. options. netpipes: Do a tar or dd over the LAN. rsync: File-by-file copy over LAN. rdist: Ditto, less well-known but with some good points. I'll have to look at that. I need dd like copies, but I don't want /media/slash to be anything but an empty dir in the image it makes. dd to a file, then use losetup -f -P to make the partitions in that file mountable, mount the appropriate one and delete the stuff you don't want. Wouldn't the file, if put on /media/slash, it seems dd would include /media/slash in that file, and the result even if it didn't get into a recursion forever loop, would still be around 10GB bigger than media//slash, and it already has some stuff on it: I was assuming that you weren't trying to dd to something on the same physical device... which would be highly inadvisable if not impossible since you need to put what you're copying from into a quiescent state (i.e. single user or as Adam pointed out fsfreeze. So either get another temporary device and connect it via USB, or use dd+netpipes to copy the device onto a different system over the LAN. I need dd like to preserve the file addresses in /boot as I've read they are expected to be at fixed addresses with this boot method. There's usually something that can't easily be moved, unless there's a loader in ROM with enough smarts to be able to drive a FAT (etc.) filesystem. Maybe it would be best if I used the resize utility to resize the / to just over whats used. I've made a copy of /home/pi/linuxcnc, so I at least have the codes I've already written backed up locally. But you'll still need to unmount / or at the very least go into single-user mode or freeze it before you can do anything like that. And I've not been able to find, but haven't looked online, a man page for rdist. Now have, but bears a re-read, its nothing like a dd. As I said above, rdist is comparable with rsync. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On 25/07/18 21:00, Adam Borowski wrote: On Wed, Jul 25, 2018 at 08:15:03PM +, Mark Morgan Lloyd wrote: Really depends what you mean by an "image backup". I do a lot of stuff using "ye olde traditional" dd, either between devices or more often making an image of the entire device (i.e. including partition table etc.) to a file and manipulate it there (e.g. by deleting a directory tree /after/ the data has been copied). However when using something like dd there's a major problem: you either want the storage medium to be removed so you can copy the filesystems offline, or you need to shut every possible piece of running software down (including things like your SSH daemon) so that nothing's writing to the disc when you're trying to copy it. Needless to say the same considerations apply when using dd to do a sector-by-sector copy from one device to another. man fsfreeze Thanks for that, I'll take a look. Some filesystems (at least btrfs) can also enumerate all writes since a certain point of time, which allows backing up the full filesystem even without freezing writes, with incremental versions done very cheaply. I fount btrfs a bit scary, with (when I last looked) too many things unimplemented and insufficient filesystem/kernel version/implementation checks. There are still ways of working round that sort of problem. For example, you can copy an entire device using dd to capture boot segments and partition layout, inspect and recreate the filesystems using mkfs, then use [something] to copy files one at a time into the new filesystems taking care that some bootloaders need a wakeup call when a file moves. Usually dd-ing the partition table and u-bootage, then rsync on filesystem data works pretty well. Unlike btrfs ways, rsync is not atomic, but most people consider it good enough. [Nod] The thing that caused me problems (on a PC) a few weeks ago was moving an OS between discs, and eventually working out that I had to forcibly update GRUB and then rebuild the initramfs to get details like the initial fstab correct. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On 25/07/18 21:30, Gene Heskett wrote: On Wednesday 25 July 2018 16:15:03 Mark Morgan Lloyd wrote: There are still ways of working round that sort of problem. For example, you can copy an entire device using dd to capture boot segments and partition layout, inspect and recreate the filesystems using mkfs, then use [something] to copy files one at a time into the new filesystems taking care that some bootloaders need a wakeup call when a file moves. As far as "something" is concerned: dd: Sector-by-sector copy between devices and files. tar: Good ol' archiver, with directory-exclude etc. options. netpipes: Do a tar or dd over the LAN. rsync: File-by-file copy over LAN. rdist: Ditto, less well-known but with some good points. I'll have to look at that. I need dd like copies, but I don't want /media/slash to be anything but an empty dir in the image it makes. dd to a file, then use losetup -f -P to make the partitions in that file mountable, mount the appropriate one and delete the stuff you don't want. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On 25/07/18 19:00, Gene Heskett wrote: On Wednesday 25 July 2018 07:22:46 Mark Morgan Lloyd wrote: I have not been successfull at "make pdfdocs", it hits something it doesn't like in the chapter on networking, not finding a file that is (or was) installed since this is now armbian, and which an apt-file find pdftex returns 262 versions of it as available. But which is the correct version? $64k question, that. Lots of stuff missing for make pdfdocs, not working yet and apt has drug in close to a gigabyte of stuff. And apt can't find half of what it wants even then. But it may have succeeded, now installing okteta, and okular another 150 megs of dependencies that pulls in for each. That's something I've never tried I'm afraid, and I suspect that most people use an online one. However if you really do need to do that I suggest looking at the manpage for make, since knowing exactly what command was being run would probably help you a lot. But lastly, because I've made some real progress, I need to make an image backup of / but without the contents of /media/slash because that is where I'll put the "backup". How the heck do I do that? And what command is used to image the sd to the eMMC? Then I'll see if it will boot from the eMMC, then have make make the debs. Seems like a logical order anyway... Really depends what you mean by an "image backup". I do a lot of stuff using "ye olde traditional" dd, either between devices or more often making an image of the entire device (i.e. including partition table etc.) to a file and manipulate it there (e.g. by deleting a directory tree /after/ the data has been copied). However when using something like dd there's a major problem: you either want the storage medium to be removed so you can copy the filesystems offline, or you need to shut every possible piece of running software down (including things like your SSH daemon) so that nothing's writing to the disc when you're trying to copy it. Needless to say the same considerations apply when using dd to do a sector-by-sector copy from one device to another. That would normally be done by putting the system into single user mode, and traditionally that was done using something like the telinit 1 command... and it was that that I complained about at the start of this thread, since I suspect it was responsible for killing an SDCard in a TinkerBoard. There are still ways of working round that sort of problem. For example, you can copy an entire device using dd to capture boot segments and partition layout, inspect and recreate the filesystems using mkfs, then use [something] to copy files one at a time into the new filesystems taking care that some bootloaders need a wakeup call when a file moves. As far as "something" is concerned: dd: Sector-by-sector copy between devices and files. tar: Good ol' archiver, with directory-exclude etc. options. netpipes: Do a tar or dd over the LAN. rsync: File-by-file copy over LAN. rdist: Ditto, less well-known but with some good points. parted: Resize a partition. resize2fs: Resize a filesystem contained in a partition. So in combination, a fairly common use case would be to dd an entire device to a file, resize2fs the final filesystem to its minimum size, parted to reduce the final partition to its minimum size, dd to put the file onto a new device (noting that even if the size is nominally the same, it's common for it to be smaller by a piffling few 100s of Mb hence the palaver of resizing) and finally expand the final partition and its included filesystem to fit. I've done rather a lot of that sort of thing, it's very much "old school". And like everybody else, on at least one occasion I've got the dd parameters wrong and roached something I really wanted to keep. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On 25/07/18 10:15, Gene Heskett wrote: On Wednesday 25 July 2018 00:49:55 Brian Sammon wrote: On Sat, 21 Jul 2018 15:42:41 -0400 Gene Heskett wrote: https://odroidinc.com/products/odroid-xu4 I have one, bricked, it has a uefi bios and at the time, the linux installer had no clue how to deal with it. The only option I could find in the bios was to disable the tcp chip, which bricked it, and a jtag programmer and adapter worth more than the odroid is required to restore it. This is NOT mentioned ANYPLACE is the sales propaganda on their site or in this link. Had they not been drinking the windows koolaid, it I'm a little confused by this. Are you saying that they put UEFI on the ODROID XU4 so that it could run Windows? As you said, this is not mentioned anyplace in the marketing info, but I can't find it mentioned anywhere else either. I also see no claims that the XU4 could run Windows. Did you ever discuss this with Hardkernel (preferably in a public forum like https://forum.odroid.com/)? Did they acknowledge or deny the UEFI situation? They acknowledged it, and told me how to fix it, but the fix cost more than the odroid, a jtag programmer and a special cable that cost well Did you get them to acknowledge this in /public/, i.e. where prospective customers can see it? over $125 is required. And someone else recently advised me that UEFI bypassing in the bios was only legal on x86 stuffs. If thats so, I'd "Only legal" in the USA, and I regret to say that it's /your/ political system that enabled things like the DMCA. push for legislation to outlaw the whole concept as it is unfair competition to me, and microsoft should owe damages to everyone that got burnt as I did. In any event, I've not been back to their site and if they starve I could care less. Get screwed once, shame on them, twice, shame on me. The only possible mention is at <https://forum.odroid.com/viewtopic.php?f=138&t=20593> Smarter folks than I might be able to build a workaround, but they were pretty carefull how that subject was covered. u-boot might be able to deal with it, but I haven't studied up on that enough to say. The rock64 gets around it but I've no clue how that works either. I have successfully built the linux-rt kernels on both the pi and the rock64, but now I cannot find a utility that will actually update the sd cards boot code to install the replacement code, and questions about how to do this seem to be ignored on all the revelant forums. zero answers other than a few links to code from 2011 & 2012 that seems to be unrelated have been supplied. I do know that dpkg knows how to deal with it as I've seen its onscreen log while doing it on the rock64, but it doesn't seem to be covered in the dpkg man pages. Also a stumbling block, make doesn't know how to "make" a vmlinuz, only huge vmlinux, and no initrd's. But I have made those. In the kernel source directory run make help | less and check the section "Architecture specific targets" towards the bottom, then what formats your loader etc. supports. As I said a few days ago, initrd is made by distro-specific tools, it has to be done that way since apart from the format it's really got very little to do with the kernel per se. It took something just over 1 hour to build that on the rock64. On an 120GB SSD mounted to /media/slash via a sata to usb-3 adapter, so I wasn't beating the sd card to death. What I'd like to do is copy that sd to the eMMC module, plugged in but empty ATM and do the installs to the eMMC memory, so it boots from a known good boot, but will use the eMMC as the bootable medium if the sd card is removed. That way I'd have a fallback rescue path if the install on the eMMC card is broken. Just plug the sd card back in and push the power button. Usual caveat about not getting anything on the eMMC that subsequently prevents you booting from SDCard etc. I for one always feel a bit queasy about writing to non-removable Flash devices. We had a removable Odroid eMMC module that died, they subsequently admitted (in public) that they'd had manufacturing problems. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 24/07/18 22:45, Gene Heskett wrote: On Tuesday 24 July 2018 16:40:38 Mark Morgan Lloyd wrote: And what does ssh -v tell you? In the shell session you're using try echo $$ which will give you the PID of that instance of bash, and then see where that appears in ps faux output. I can do that, I hope that effort bears fruit, this and another r-pi 3b has had a habit of throwing away local keyboard and mouse events. Another reboot might fix it, and then again it might be worse. But I expect this is a different breed of horse. http://www.lab-initio.com/screen_res/nz174.jpg Chuckle. The caption originally continued with something like "I can fit you in a week Thursday" but the author moved site and started colouring them. But that ps output does appear to imply that you've got a running shell, so the question might be moving from sshd towards something silly like an endless loop in your .bashrc Thats not been touched by me in nearly a year. But I'll go look anyway. And here is an interesting observation, a lowercase -y works, the uppercase doesn't: You do appreciate I trust that -Y and -y are completely unrelated? And now with all the fooling around, I can't restart the ssh service on this machine, getting this error: gene@coyote:~/Public/rock64-next-try$ service ssh start [] Starting OpenBSD Secure Shell server: sshdCould not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_dsa_key . ok So it looks like it's unhappy with ssh_host_rsa_key but ssh_host_dsa_key is OK. Does it actually still work? I think I'd better quit while I still have a network. but do they exist?: yes: gene@coyote:~/Public/rock64-next-try$ ls -l /etc/ssh total 272 -rw-r--r-- 1 root root 242091 Apr 30 2014 moduli -rw-r--r-- 1 root root 1733 Nov 27 2016 ssh_config -rw-r--r-- 1 root root 2557 Nov 27 2016 sshd_config -rw--- 1 root root668 Feb 3 2015 ssh_host_dsa_key -rw-r--r-- 1 root root601 Feb 3 2015 ssh_host_dsa_key.pub -rw--- 1 root root227 Feb 3 2015 ssh_host_ecdsa_key -rw-r--r-- 1 root root173 Feb 3 2015 ssh_host_ecdsa_key.pub -rw--- 1 root root 1675 Feb 3 2015 ssh_host_rsa_key -rw-r--r-- 1 root root393 Feb 3 2015 ssh_host_rsa_key.pub So I am lost. Thanks Mark. Now I'm getting back to my various RPi etc. problems, which boil down to iperf giving me chaotic timing results on high-latency 4G links. Attractors at 3.75, 7.5, 15, 30, 45 MBits/sec. Fun :-/ -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rpi, now no shell for an ssh login
On 24/07/18 20:45, Gene Heskett wrote: On Tuesday 24 July 2018 14:23:33 Mark Morgan Lloyd wrote: haven't tried the ssh -v, which machine? The output of service ssh status, on the pi looks legit as its the log of successfull stuff from the data there. On the machine you run ssh on, obviously (That's "ssh" the command, not "SSH" the protocol etc. :-) Since I am careing for an invalid wife, I'd better go fix us something to eat, later Mark, and thank you. Dagnabbit Gene, I wish there weren't two ways of pronouncing that word :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 24/07/18 20:15, Gene Heskett wrote: On Tuesday 24 July 2018 14:29:49 Mark Morgan Lloyd wrote: So you get the password prompt which is actually issued by your SSH client. The two things I'd suggest are (i) if you have one use a shell session on the local console to run something like ps faux | less so you can see whether the ssh daemon's stuck running something. Look in /var/log/messages etc. Try ssh without the -Y then again with the -v option. Sorry for being concise, but evening passes and I've spent all day on RPi OSes and several nay many days trying to sort out throughput issues... SSH login should /not/ be a problem. The only thing I can see that sshd related: /usr/sbin/sshd -D \ sshd: pi [priv] \ sshd: pi@pts/1 \ /bin/bash There was one other entry, clear at the bottom of a lengthy list: sshd \ bin/bash but I think that was the terminal I was using. Or is that the hung one??? dunno. And what does ssh -v tell you? In the shell session you're using try echo $$ which will give you the PID of that instance of bash, and then see where that appears in ps faux output. I hope that effort bears fruit, this and another r-pi 3b has had a habit of throwing away local keyboard and mouse events. Another reboot might fix it, and then again it might be worse. But I expect this is a different breed of horse. http://www.lab-initio.com/screen_res/nz174.jpg But that ps output does appear to imply that you've got a running shell, so the question might be moving from sshd towards something silly like an endless loop in your .bashrc -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
I get the pw requester, answer it, get the login blurb I assume from /etc/issue.net, but then no shell prompt in the remote term emulator, and a ctrl-d is also ignored. Kill the tab is the only way out. Thinking I had hit some limit on this machine. or on the pi, I got exactly the same results from the rock64's keyboard before and after rebooting the pi. So whats next? So you get the password prompt which is actually issued by your SSH client. The two things I'd suggest are (i) if you have one use a shell session on the local console to run something like ps faux | less so you can see whether the ssh daemon's stuck running something. Look in /var/log/messages etc. Try ssh without the -Y then again with the -v option. Sorry for being concise, but evening passes and I've spent all day on RPi OSes and several nay many days trying to sort out throughput issues... SSH login should /not/ be a problem. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rpi, now no shell for an ssh login
On 24/07/18 17:45, Gene Heskett wrote: Now to see if the pi can be fixed, but the second of those two commands does not exist in /etc/ssh/sshd_config on the pi, even there but commented out. But I have not made it work on the pi, with or without the X11UseLocalhost no (the default it says) line, i get a login requestor, enter my pw, and get the login blurb, but then no shell. I have not rebooted the pi, I guess thats next... Didn't help, I can login from here, or from the new armbian install on the rock64, but I get no shell after the signed in blurb. Let's try to make some sense of this. You've got /what/ /exactly/ running on the RPi: Raspbian Jessie? Can you log in using an attached screen/keyboard? As both GUI and text (i.e. in the latter case using to get a text login prompt)? Can you either login as root or do a sudo su or whatever? Does ifconfig tell you that the expected interface exists and has the expected address? > And the /etc/passwd says I get /bin/bash... No it doesn't, it says that it's to use it provided that it's installed. Does /bin/bash exist? Does the home directory exist (that's a very common problem)? Now provided that the above is OK, let's look at SSH which is what I /think/ you're asking about. Presumably you can ping the RPi and get a response back (i.e. your route is OK), what /exactly/ happens when you try to SSH to it? Does ssh -v throw any light on it? Can you try from a PC rather than your Rock64? Logging into Raspbian Jessie is something I do on a very regular basis. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 24/07/18 17:15, Gene Heskett wrote: On Tuesday 24 July 2018 10:07:45 Lennart Sorensen wrote: On Tue, Jul 24, 2018 at 04:21:25AM -0400, Gene Heskett wrote: And that works, geany now runs on the rock64 from an ssh login!!!. Now to see if the pi can be fixed, but the second of those two commands does not exist in /etc/ssh/sshd_config on the pi, even commented out. And when added, results in a login with no shell prompt. So I used another login already established to remove that line again, but a ssh restart, logout and log back in does not get me a shell prompt after entering the password. So now I am locked out of the pi due to lack of a shell. But the rock64 now gives me x exports. Great. Some progress finally. Yep, and I've made it work for an armbian install this morning too! Big grin. But I had a heck of a time getting a gateway to "stick" thats very fragile. Seems there is more stuffs now required in /e/n/i.d/eth0 than before, and no 100% reliable way to get it all started, so while its now working, I'd have to say its fragile yet using the new way. Extra stuff /such/ /as/? I find this allow-hotplug eth0 iface eth0 inet static address 192.168.1.19/24 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.1.1 dns-search telemetry.co.uk to be entirely adequate for /etc/network/interfaces on Raspbian and Debian Stretch, except possibly for the TinkerBoard I was looking at a few days ago. But now, moving 15 feet to the pi, trying to do it on the pi, which is running a jessie install, I've lost the shell after a login. So my logins are useless. They echo what I type, but nothing see's the return except the echoing linefeed. So kind people, whats next to check? Please describe the problem exactly. Most of us are reading this while working etc., assume our memory is limited. Debian or Raspbian Jessie? Main console? Text? GUI? Manual or auto login? SSH? What shell? and so on. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 24/07/18 08:30, Gene Heskett wrote: On Tuesday 24 July 2018 01:28:41 Tixy wrote: On Mon, 2018-07-23 at 18:53 -0400, Gene Heskett wrote: When you said you had isses with ssh -Y not allow X connections... Check that /etc/ssh/sshd_config on the rock64 has these settings: X11Forwarding yes X11UseLocalhost no And that the package 'xauth' is installed. Either of those missing will prevent ssh from forwarding X connections. Do I have to reboot it (the rock64) after makeing everything as above? Logging out, and back in does not shut the error message off. I expect you'll need to restart the ssh daemon, e.g as root: # service ssh restart And that works, geany now runs on the rock64 from an ssh login!!!. Now to see if the pi can be fixed, but the second of those two commands does not exist in /etc/ssh/sshd_config on the pi, even commented out. Agreed, I don't see it either on Raspbian or on the 32-bit Debian build I've got for an RPi2/3. IME it's the first which is important. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 23/07/18 19:45, Cindy-Sue Causey wrote: On 7/22/18, Mark Morgan Lloyd wrote: It's regrettable that dpkg-reconfigure doesn't have something like a --list command which summarises the packages to which it may be applied, or even a --search which works by analogy with apt-cache etc. There's always the option of submitting something like that as a reportbug wishlist item. I verified first using grub-pc. Had to flip through over 500 bugs (*OUCH!*) to get to the point where you choose wishlist, but it *is* there in the options regarding a bug report's severity level. Ouch. I most regret that I've spent much more time working round bugs and arguably-missing features than I should have done, rather than engaging with various distreaux's bug management systems and then brushing up on my C, scripting and package management skills. Story of my life: "I'm sure I can hack past this, after which I'll be in the open and the way will be clear". -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 23/07/18 16:45, Lennart Sorensen wrote: On Mon, Jul 23, 2018 at 12:00:19PM -0400, Gene Heskett wrote: First I am logging in as user 1000, aka pi on the pi and rock64 on the rock64. Root logins are disallowed. I can sudo later, but can't run anything that needs x, getting the can't open display :11 or some such twaddle error. And I've no clue if ts this wheezy machine, or that jessie or stretch machine reporting the error I see on my konsole here on wheezy. Once you su or sudo you no longer have permission to access X. If you want that use gksudo or kdesudo which handle keeping access to X while switching to root. Sudo's -E option very often helps. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Cautionary tale: how to kill an SDCard with one simple command
On 23/07/18 15:30, Lennart Sorensen wrote: On Sat, Jul 21, 2018 at 09:18:56PM +, Mark Morgan Lloyd wrote: We've got an ODroid. The impression I got was that the hardware was fairly well done, but that the distro that came with it (some variant of Ubuntu) rather less so... the usual things about missing dependencies which can make things very flaky (e.g. autoremove broke X11 beyond repair). My recollection of the UEFI situation is that Intel et al. made "Secure Boot" optional on PCs but mandatory on ARM systems that had UEFI. Microsoft made that a rule for devices that are Windows Certified. x86 devices with Windows should have an option to let the user decide about secureboot (but it must be on by default), while arm devices must always use secureboot with Windows. Intel had nothing to do with that. Thanks for the clarification, which I also came across when I checked after opening my mouth (rather than, as is politic, before :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 23/07/18 10:30, Gene Heskett wrote: On Monday 23 July 2018 06:09:01 John Holland wrote: shot. It can't be any worse of a C.F. than the ayufan builds with its pre-allocated user 1000. Although having a preallocated user 1000 is the standard "Debian Way", the objective being that you can telnet (later SSH) in using that user and then sudo su to get root (fouled up on some versions that don't add user 1000 to sudoers). For quite a long time The same effect can be achieved by supplementing the user in question with the group sudo. With that there is no need to edit sudoers. John But that does not fix the x server being locked and unusable when logged in from a comfy chair because user 1000 is not the same name. So you are limited to ncurses at best for a gui. And that sucks somewhere around 10-35 Torr. Gene, what /exactly/ are you complaining about here? if it's simply that you can't get a GUI login as root from your system console then that's a display manager thing which should be fixable. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 23/07/18 10:15, John Holland wrote: shot. It can't be any worse of a C.F. than the ayufan builds with its pre-allocated user 1000. Although having a preallocated user 1000 is the standard "Debian Way", the objective being that you can telnet (later SSH) in using that user and then sudo su to get root (fouled up on some versions that don't add user 1000 to sudoers). For quite a long time The same effect can be achieved by supplementing the user in question with the group sudo. With that there is no need to edit sudoers. ..some versions which neither add user 1000 to sudoers, nor add user 1000 to the sudo group. And so on :-) The bottom line is that there's longstanding doctrine that you don't send a root password over Telnet, and slightly more recent doctrine that the prevalence of keyloggers makes it highly undesirable to enter a root password into an unsecured desktop system. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 23/07/18 08:30, Gene Heskett wrote: On Monday 23 July 2018 00:11:14 Alan Corey wrote: Yeah, this is maybe the 3rd time I've been on IRC, I guess I've given up trying to get it to work on my phone. Some of it's interesting reading. I'm alan01346 on there. Page 8, "Fig. 1-1 RK805 One Battery Cell Application" is what I meant. I suppose it's possible it works but most people don't use it so it isn't well documented. Even in fig 1-1 I can't tell where the battery is. It has a sleep mode and an alarm. Page 19 (by xpdf) shows registers for seconds, minutes, hours, etc. More on page 21-26. I searched the IRC for battery and found: 26/12/17 01:37 I can provide circuit how to add 3V battery power to existing schematic for RTC power 28/02/18 21:23 the white connector is for the RTC battery I would assume this battery is for a ups like function. And I just noticed something about the armbian release of stretch available on the pine site. The initial login is as root, meaning one can probably addusr his own named account as user 1000. This would solve several problems I believe, so I have that image coming in now, and if I have time later today I'll burn it to an sd card and give it a shot. It can't be any worse of a C.F. than the ayufan builds with its pre-allocated user 1000. Although having a preallocated user 1000 is the standard "Debian Way", the objective being that you can telnet (later SSH) in using that user and then sudo su to get root (fouled up on some versions that don't add user 1000 to sudoers). For quite a long time you've only been able to login as root from the system console (i.e. the directly-connected keyboard and screen) and I think in at least some cases (display manager specific) you can't get to a GUI as root: you have to do a etc. You can change whether root can get a GUI from system-specific display manager configuration. You can change whether you can SSH in as root in SSH configuration files. I've not seen a situation on Debian- but have on Solaris- where one has to muck around with PAM to change this, which TBH is a fairly common requirement during system setup. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 22/07/18 21:30, Gene Heskett wrote: On Sunday 22 July 2018 14:58:33 Mark Morgan Lloyd wrote: On 22/07/18 15:15, Gene Heskett wrote: On Sunday 22 July 2018 10:11:04 Mark Morgan Lloyd wrote: On 22/07/18 14:00, Gene Heskett wrote: I have a bunch of locale related errors too. Was a stretch-minimal install by ayufan, has xfce for desktop What am I missing? The traditional command for that was tzconfig, but these days it will tell you to run dpkg-reconfigure something... WARNING: the tzconfig command is deprecated, please use: dpkg-reconfigure tzdata Worked a treat, thank you. It's regrettable that dpkg-reconfigure doesn't have something like a --list command which summarises the packages to which it may be applied, or even a --search which works by analogy with apt-cache etc. And if my well aged wet ram is to be trusted, it used to do a lot more than it is now, only setting two items in the locales now. Or its been stripped to do the bare minimum on a rock64/arm64. Dunno which, but its a dissapointment, just like the networking is broken in that it cannot apply a gateway to a static setup without doing a separate command with route once its booted. Putting the gateway address into /e/n/i.d/eth0 is simply ignored. I even moved it to /e/n/i, no effect. Yesterday I tried changing the static address, took 3 powerdown reboots to actually get that to take, and 2 reboots to restore the original which was easier than editing every /e/hosts file on my local network. A networking restart totally ignores anything you do in /e/n/i. Sounds crazy and impossible, but thats how it works here. Depressing is what it is What I'd say is that with pukka Debian on PCs and Raspberry Pis (and in the latter case also Raspbian, although note that I'm making a distinction) up to Buster (on PCs) and Stretch (on RPis) /e/n/i works as expected. I have however just dug out this note # In /etc/NetworkManager/NetworkManager.conf an entry like # [keyfile] # unmanaged-devices=mac:b8:27:eb:86:2f:e6 # will prevent a device from being brought (half-)up by Network Manager. although I can't remember the extent to which I actually needed it in the end. The TinkerBoard I was testing the other day had an interface naming problem, apparently brought about by the fact that it had all drivers built into the kernel binary rather than stored as modules... presumably the maintainers thought that if they did that it would make the card removable (but see my heads-up about putting it into single-user mode the other day). NetworkManager is an unremitting nuisance IMO except for the specific case it was designed for, which is a laptop moving between WiFi access points. ModemManager is little better, but regrettably is a prerequisite for usb-modeswitch. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 22/07/18 15:15, Gene Heskett wrote: On Sunday 22 July 2018 10:11:04 Mark Morgan Lloyd wrote: On 22/07/18 14:00, Gene Heskett wrote: I have a bunch of locale related errors too. Was a stretch-minimal install by ayufan, has xfce for desktop What am I missing? The traditional command for that was tzconfig, but these days it will tell you to run dpkg-reconfigure something... WARNING: the tzconfig command is deprecated, please use: dpkg-reconfigure tzdata Worked a treat, thank you. It's regrettable that dpkg-reconfigure doesn't have something like a --list command which summarises the packages to which it may be applied, or even a --search which works by analogy with apt-cache etc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On 22/07/18 14:00, Gene Heskett wrote: I have a bunch of locale related errors too. Was a stretch-minimal install by ayufan, has xfce for desktop What am I missing? The traditional command for that was tzconfig, but these days it will tell you to run dpkg-reconfigure something... WARNING: the tzconfig command is deprecated, please use: dpkg-reconfigure tzdata -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Cautionary tale: how to kill an SDCard with one simple command
On 21/07/18 19:45, Gene Heskett wrote: And something is wrong with the locale, even a "dpkg-reconfigure locale" cannot create the locale vars needed. Getting a 9 line complaint from perl for every file processed. Referring to my notes for setting up pukka Debian on an RPi I note that the commands I used were dpkg-reconfigure locales dpkg-reconfigure console-data plus checking the content of /etc/default/locale -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Cautionary tale: how to kill an SDCard with one simple command
On 21/07/18 19:45, Gene Heskett wrote: On Saturday 21 July 2018 14:58:35 gru...@manlymail.net wrote: take a look at https://odroidinc.com/products/odroid-xu4 I have one, bricked, it has a uefi bios and at the time, the linux installer had no clue how to deal with it. The only option I could find in the bios was to disable the tcp chip, which bricked it, and a jtag programmer and adapter worth more than the odroid is required to restore it. This is NOT mentioned ANYPLACE is the sales propaganda on their site or in this link. Had they not been drinking the windows koolaid, it might have been able to do my job, but AFAIAC, they sold me the s.o.b. under false pretenses. That bios according to US law, is sick bird as there is supposed to be a way it can be turned off, but there is not. We've got an ODroid. The impression I got was that the hardware was fairly well done, but that the distro that came with it (some variant of Ubuntu) rather less so... the usual things about missing dependencies which can make things very flaky (e.g. autoremove broke X11 beyond repair). My recollection of the UEFI situation is that Intel et al. made "Secure Boot" optional on PCs but mandatory on ARM systems that had UEFI. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Cautionary tale: how to kill an SDCard with one simple command
On 21/07/18 16:00, Gene Heskett wrote: On Saturday 21 July 2018 10:20:02 Mark Morgan Lloyd wrote: I'd been comparing the performance of a Rockchip-based board's LAN and USB against an RPi3B+, results were satisfactory. There's a modicum of muttering that the 3B+ has broken something relating to the LAN or USB. I'm convinced its the internal usb2 hub that all i/o except the radio and spi has to go thru. It has a rather annoying tendency to throw away its own mouse and keyboard events. Thats not at all a pleasant occurrance when the tossed event is a keyup, and it left 1500 lbs of machinery moving with no stop except crashing into something. OTOH, once code has been coaxed into a file, that file can run that same machinery to do micron accurate work. The machine control is thru spi, writing 32 bit packets at 41 megabaud, and reading the responses 32 bits at a pop at 25 megabaud. The focus of people's ire ATM appears to be the RPi3B+, where the design has changed the chip that implements LAN and USB hub functionality. Over the last few days I've put a lot of time into this as the culmination of a ridiculous amount of routing/firewalling testing, and while I'd quite like to be able to accumulate more results what I can say so far is that while a TinkerBoard can receive a data stream over 1GBit/sec Ethernet and farm it out to at least three USB-connected 100MBit adapters before performance starts degrading, an RPi3B+ can only handle one and when a second is added performance is distributed unevenly... don't even dream of adding a third. The RPi range is good for what it was initially designed for, but that LAN/USB chip appears to be its weakness. I've not sought out a datasheet or worked my way through the kernel yet, but it looks as though there's some sort of prioritisation in there that can get out of kilter. Gene, is it one of these https://www.pine64.org/?product=rock64-media-board-computer that you're currently running to good effect? Remainder noted with interest. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Cautionary tale: how to kill an SDCard with one simple command
On 21/07/18 14:00, Gene Heskett wrote: On Saturday 21 July 2018 07:46:38 Mark Morgan Lloyd wrote: I wanted to do a bit of low-level maintenance yesterday evening on a TinkerBoard (Rockchip RK3288) running Stretch, so as an old PC hand I ran telinit 1 At that point the SDCard became a boat anchor. Now I'm obviously not entirely sure about this, and it /could/ be an unfortunate coincidence. But unless absolutely sure, it might be a hack best avoided. I've used 'ssh -Y user@hostname' for that telnet connection for ages, and cannot recall toasting an SD card doing it. I also use an sshfs mount for moving stuff around. It seems to work for me with a lot less hassle than an nfsv4 mount ever has. ymmv of course. That's absolutely nothing to do with telnet, that puts the OS into single-user mode and I suspect it killed something that was necessary for the survival of the card- or perhaps it just killed something at a highly inopportune time. I'd been comparing the performance of a Rockchip-based board's LAN and USB against an RPi3B+, results were satisfactory. There's a modicum of muttering that the 3B+ has broken something relating to the LAN or USB. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Cautionary tale: how to kill an SDCard with one simple command
I wanted to do a bit of low-level maintenance yesterday evening on a TinkerBoard (Rockchip RK3288) running Stretch, so as an old PC hand I ran telinit 1 At that point the SDCard became a boat anchor. Now I'm obviously not entirely sure about this, and it /could/ be an unfortunate coincidence. But unless absolutely sure, it might be a hack best avoided. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: missing gw in route -n
On 13/07/18 15:15, Gene Heskett wrote: On Friday 13 July 2018 10:49:10 Mark Morgan Lloyd wrote: Yes, and route (and ifconfig etc.) is obsolete. But still sometimes useful. And will probably continue to be usefull as long as the man pages for ip and friends continue to suck dead toads thru soda straws. Or something is changed to totally disable the old standby's. At which point we'll all have to learn how to use them, but this list and its collective knowledge will become the man pages for ip and kin that should have been written in the first place. Keyword is examples, few to non-existent. Seriously Gene, you /do/ have to watch out there since the newer replacements (documented as ip-route etc.) can put things into kernel tables that the "classic" route command cannot describe adequately. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: missing gw in route -n
And the last automatic updates were done on the 7th June- correct? Much stuff that I do these days is based on RPIs which don't use an initrd, but I had to go through this on a PC a few weeks ago after I'd moved some discs around: the old configuration was still stuck in the fstab file loaded from the initrd file. I think it was a simple update-initramfs -u that got me going, but (a) check your manpages etc. and (b) if EFI really is involved check whether the boot loader requires any file signing etc... I'm afraid I've only used EFI on Itanium and there only superficially. The EFI directory is empty. These arm semi-clones have virtually no identifiable bios. But they do have a loader of some sort, pulling in the kernel, dtd, and initrd. But I did just now get it fixed, my syntax for route add was fubar, it should have been: root@rock64:/etc/network# cat make-missing-gateway.sh route add default gw 192.168.71.1 dev eth0 I was missing the default and dev options. routes manpage sucks. Yes, and route (and ifconfig etc.) is obsolete. But still sometimes useful. In practice, "default" substitutes for "-net x.y.z.t" and so on. Nice, uniform syntax :-( This was the answer to the question I asked several times in this thread and which was universally ignored by 99% of the responders. Thanks Mark. Perhaps this fix will be usefull to others. But the major thing you were asking was why your interfaces file was being ignored. You might still have that one lurking. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: missing gw in route -n
On 13/07/18 13:45, Gene Heskett wrote: On Friday 13 July 2018 05:08:57 Mark Morgan Lloyd wrote: On 13/07/18 02:00, Gene Heskett wrote: Thats a direct copy/paste, so whats wrong with that. Other than the fact that its been rebooted twice since the address was changed from 192.168.71.2 to the 11 you see above, but ifconfig still says its on 71.2 right now. So where the heck is it getting the .2 address. Possibly from an initrd file that needs to be rebuilt. That is not a grub using boot scheme, and I have not the knowledge to do that. The booting of these things is as yet a mystery to me. An ls -l of /boot might disclose the boot method to trained eyes: root@rock64:/etc/network# ls -l /boot total 27048 -rw-r--r-- 1 root root 4660138 May 27 18:39 System.map-4.4.126-rockchip-ayufan-239 -rw-r--r-- 1 root root 148020 May 27 18:39 config-4.4.126-rockchip-ayufan-239 lrwxrwxrwx 1 root root 59 Jun 7 21:32 dtb -> dtbs/4.4.126-rockchip-ayufan-239/rockchip/rk3328-rock64.dtb lrwxrwxrwx 1 root root 59 Jun 7 21:32 dtb-4.4.126-rockchip-ayufan-239 -> dtbs/4.4.126-rockchip-ayufan-239/rockchip/rk3328-rock64.dtb drwxr-xr-x 3 root root 4096 May 27 19:15 dtbs drwxr-xr-x 3 root root16384 Jan 1 1970 efi -rw-r--r-- 1 root root 7940 Apr 27 11:26 filesystem.packages -rw-r--r-- 1 root root1 Apr 27 11:26 filesystem.packages-remove -rw-r--r-- 1 root root 3119706 Jun 7 21:32 initrd.img-4.4.126-rockchip-ayufan-239 -rwxr-xr-x 1 root root 19726344 May 27 18:39 vmlinuz-4.4.126-rockchip-ayufan-239 And the last automatic updates were done on the 7th June- correct? Much stuff that I do these days is based on RPIs which don't use an initrd, but I had to go through this on a PC a few weeks ago after I'd moved some discs around: the old configuration was still stuck in the fstab file loaded from the initrd file. I think it was a simple update-initramfs -u that got me going, but (a) check your manpages etc. and (b) if EFI really is involved check whether the boot loader requires any file signing etc... I'm afraid I've only used EFI on Itanium and there only superficially. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: missing gw in route -n
On 13/07/18 09:15, John Paul Adrian Glaubitz wrote: Or, alternatively: Set up systemd-networkd and systemd-resolved and don't waste endless amounts of time and energy to get this mess fixed which is bash-script-based network initialization. ..which is something that those of us who are investing significant resources into complex routing and firewalling intend- for the moment at least- to stick with, to the extent of migrating to a different distro if necessary. If- as you appear to be saying- Debian is knowingly shipping stuff in a broken state then my only response can be that we've got enough problems of our own without trying to fix yours. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: missing gw in route -n
On 13/07/18 02:00, Gene Heskett wrote: Thats a direct copy/paste, so whats wrong with that. Other than the fact that its been rebooted twice since the address was changed from 192.168.71.2 to the 11 you see above, but ifconfig still says its on 71.2 right now. So where the heck is it getting the .2 address. Possibly from an initrd file that needs to be rebuilt. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: missing gw in route -n
On 12/07/18 05:00, Gene Heskett wrote: Greetings; I have been playing the 10k monkeys scene trying to figure out how to add a gateway entry to the route -n report on a rock64 with a stretch/xfce install on it. Where does this assignment belong in a static defined eth0 configuration? I know several places where it doesn't work, but what I need to know is where do I put, in what file, the "gateway = www.xxx.yyy.zzz" and make it just work for a stretch install on a rock64. Thats an arm64 family card. All I have been able to get out of route is the gibberishy help when there is a syntax error. The obvious (to me that is) place would be in /etc/network/interfaces.d/eth0, which has this: auto eth0 allow-hotplug eth0 iface eth0 inet static address 192.168.71.2 netmask 255.255.255.0 gateway 192.168.71.1 dns-nameserver 192.168.71.1 Start off with ifconfig -a to check your interface names, if you've got eth1 rather than eth0 look in something like /etc/udev/rules.d/70*. Working in /etc/network/interfaces, simplify your config to something like allow-hotplug eth0 iface eth0 inet static address 192.168.71.2/24 gateway 192.168.71.1 dns-nameserver 192.168.71.1 post-up echo ifup > /tmp/eth0 Note that for the dns-nameserver to work you'll need the resolvconf package. Look for /tmp/eth0 which should contain a message telling you that the "post-up" ran. If it's not there find what's going wrong, there's a file which in principle tells NetworkManager to never under any circumstances touch an interface but TBH I've yet to find a circumstance in which NM is less trouble than it's worth and very often I just tell systemd not to run it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Can't bring up the network
On 07/06/18 16:00, Jerry Stuckle wrote: A little background. I have Debian-arm 3.2.0-4-vexpress running under QEMU. This has been working fine, but in serious need of an upgrade. So I ran apt-get update and apt-get upgrade. This resulted in a long process of updating packages. Unfortunately, the hosting system crashed while the upgrade was running. This resulted in some packages which were only partially installed. In trying to get things back I found the network interface (eth0) did not come back up. Trying to start it with ifup eth0 results in Might be worth trying with ifconfig eth0 up or whatever, followed possibly by adding routes manually. /bin/sh: 1: run-parts: Exec format error Failed to bring up eth0 Adding --verbose gives run-parts --exit-on-error --verbose /etc/network/if-pre-up.d /bin/sh: 1: run-parts: Exec format error Failed to bring up eth0 /etc/network/if-pre-up.d is empty, which is what I suspect is the cause of the problem. However, I don't know what should be in there on this system - or what package is supposed to install it. QEMU is emulating a standard ethernet port (not wifi). Other systems I have installed use wifi, so will (obviously) have something different in here. Looking at a couple of fairly clean systems here, that directory contains either a vlan script or a wpasupplicant symlink. In at least one case the script is rigged to return 0 if the prerequisite executable doesn't exist... you could try creating something like vlan owned root:root mode 755 containing a shebang and exit 0, but TBH I think it's more likely that some prerequisite library's screwed. Sorry I can't be more help but I'm comparatively unpracticed at "The Debian Way": I'm a refugee from Yggdrassil and they say you never forget your first distro :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Busbox missing fdisk and fsck: How to add?
On 23/05/18 02:15, Paul Wise wrote: I don't know how big the busybox fdisk/fsck support is, but it might be worth reporting a bug on busybox asking for them to be enabled. Alternatively, a bug report asking for a busybox-static-full package containing support for every busybox applet might be a good idea. Please excuse a comment from a lurker, but I'd suggest that it would be worth having at least fdisk -l capability enabled by default since one of the first things one wants to do when in any sort of development or recovery situation is to work out what media is attached and whether it's partitioned or a single fiefsystem. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Device trees
Somebody's trying to flesh out the Device tree article on Wikipedia, but like myself is not confident that he knows what he's talking about. Allowing for the mutual dependency of ARM Linux and device trees, if anybody is confident in their knowledge and has time to enhance the article I'm sure that it would be very much appreciated by the overall community. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Module aliases etc.
On 20/02/18 16:45, Lennart Sorensen wrote:
On Sat, Feb 17, 2018 at 12:05:13PM +, Mark Morgan Lloyd wrote:
I'm trying to disentangle some driver issues so that I can backport a module
for a colleague with a weird peripheral. Can anybody tell me what the "b"
field here is, and in particular the significance of the number (3 or 5 in
the example below)?
alias: hid:b0003g*v056Ep010D
alias: hid:b0003g*v056Ep010C
alias: hid:b0003g*v056Ep00FF
alias: hid:b0003g*v056Ep00FE
alias: hid:b0005g*v056Ep0061
I'd assumed from udev/hwdb that it was a bus identifier applicable to
something that was actually plugged in, but I'm curious to see it varying on
a virgin system that's never seen the peripheral in question.
Well the kernel source code says:
return scnprintf(buf, PAGE_SIZE, "hid:b%04Xg%04Xv%08Xp%08X\n",
hdev->bus, hdev->group, hdev->vendor, hdev->product);
Also:
switch (hdev->bus) {
case BUS_USB:
bus = "USB";
break;
case BUS_BLUETOOTH:
bus = "BLUETOOTH";
break;
case BUS_I2C:
bus = "I2C";
break;
default:
bus = "";
}
So it appears to be a bus type. 3 is USB, 5 is BLUETOOTH according to input.h
Thanks very much, got it. So apparently includes things like the 8042
keyboard controller and so on.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Module aliases etc.
I'm trying to disentangle some driver issues so that I can backport a module for a colleague with a weird peripheral. Can anybody tell me what the "b" field here is, and in particular the significance of the number (3 or 5 in the example below)? alias: hid:b0003g*v056Ep010D alias: hid:b0003g*v056Ep010C alias: hid:b0003g*v056Ep00FF alias: hid:b0003g*v056Ep00FE alias: hid:b0005g*v056Ep0061 I'd assumed from udev/hwdb that it was a bus identifier applicable to something that was actually plugged in, but I'm curious to see it varying on a virgin system that's never seen the peripheral in question. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: screenblanker vs login
On 14/02/18 15:30, Mark Morgan Lloyd wrote: On 13/02/18 18:00, Alan Corey wrote: No, I think it's at a lower level than X. See if just a plain text screen blanks. I tracked it down once under OpenBSD and turned it off but they have different names for things and that was 10 years or so ago. Apologies if I'm grabbing the wrong end of the stick etc. I'm currently wrestling with this using an ASUS Tinkerboard (RK3288 -based) running TinkerOS/Linaro and I think there are several different problems: a) Disabling the GUI (window manager, desktop environment etc.) screen saver/blanker. b) Telling the X11 server not to try to shut the screen down. That might require something like xserver-command=X -s 0 dpms (note: no leading dash) in lightdm.conf (or the equivalent for other display managers). If you don't do that, remote X11 (possibly also VNC) logins go irrecoverably black after ten minutes (that one thanks to a reminder in the Raspberry Pi foramina). c) On the main text console (or possibly in a startup script): setterm -blank 0 (Found on a Slackware system I set up 15 years ago). d) Plus at least one other that I've not tracked down yet :-/ There's a syslog message like rk3x-i2c ff65.i2c: flags from: 0, 1, addr: 0x1b approximately synchronised with the "winks", but I think that's a coincidence. TODO: disable i2c to see if it changes things. It behaved itself for a few hours after I'd used setterm -blank 0 as root on the physical text console, but all of a sudden started again. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: screenblanker vs login
On 13/02/18 18:00, Alan Corey wrote: No, I think it's at a lower level than X. See if just a plain text screen blanks. I tracked it down once under OpenBSD and turned it off but they have different names for things and that was 10 years or so ago. Apologies if I'm grabbing the wrong end of the stick etc. I'm currently wrestling with this using an ASUS Tinkerboard (RK3288 -based) running TinkerOS/Linaro and I think there are several different problems: a) Disabling the GUI (window manager, desktop environment etc.) screen saver/blanker. b) Telling the X11 server not to try to shut the screen down. That might require something like xserver-command=X -s 0 dpms (note: no leading dash) in lightdm.conf (or the equivalent for other display managers). If you don't do that, remote X11 (possibly also VNC) logins go irrecoverably black after ten minutes (that one thanks to a reminder in the Raspberry Pi foramina). c) On the main text console (or possibly in a startup script): setterm -blank 0 (Found on a Slackware system I set up 15 years ago). d) Plus at least one other that I've not tracked down yet :-/ -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: OpenJDK-jre and sun.arch.abi
On 08/02/18 10:15, Arne Ploese wrote: Hi, Im trying to figure out under java what platform Im on. there are some System properties, but on the debian arm platform "sun.arch.abi" is missing. This would give me the distiction between gnueabi and gnueabihf - wether I have hard or soft floating point. On the raspberry PI3 its defined... Presumably that's an RPi3 running Raspbian (i.e. not Debian per se), which I believe explicitly licenses stuff from Oracle. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: arm64 support? When?
On 14/01/18 11:00, Gene Heskett wrote: I can't find a stretch release for a rock64. Thats not an armhf, but an arm64. Is this relevant? https://github.com/ayufan-rock64/linux-rootfs/releases -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: found net prob, temp fixed. installed xfce4, how to autostart it?
On 26/09/17 19:45, Gene Heskett wrote: On Tuesday 26 September 2017 04:23:39 Andrew M.A. Cater wrote: On Sun, Sep 24, 2017 at 10:09:02PM +, Andrew M.A. Cater wrote: Same hardware and base system here.You might need to add a login manager - I'll check :) Stock rocks64 stretch image Just sudo su - as below. Use tasksel to install LXDE - it "just works" How about xfce4? Its wm seems more complete. The question is which one is the most likely to use the mali gfx drivers on an arm64? It should not, on a modern distro, be necessary to mess around with installing components of X11 manually. I do fairly regularly find myself changing the display manager to make sure I've got XDMCP, the current best (in a shrinking field) appearing to be lightdm. I've just been looking at this again and the problem appears to affect both the main screen and a remote X11 session. I've not tried over VNC, but this looks like being a desktop or possibly display manager problem rather than hardware or lower-level drivers: things like a graphical dialog(ue) warning that SSH has been enabled but the password is still set to the default appear, and at least parts of the display manager login work; going beyond that doesn't. /var/log/syslog has some messages warning that some freedesktop.org stuff can't be found. I believe this is Raspbian-specific and as such is outside the scope of this mailing list. That's really as far as I'm going, because while Raspbian Lite or pukka headless Debian is on my critical path having a desktop environment isn't. And right now my path is pretty darned critical... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: need sd card backup on r-pi-3b
On 25/09/17 14:30, Gene Heskett wrote: On Monday 25 September 2017 05:15:36 Mark Morgan Lloyd wrote: I believe lo is now inserted automatically. Its not mentioned as a builtin in the debian handbook pdf, I read the networking section yesterday looking for clues. I've another machine about 3 feet from the rock64 thats logged into their forum. A virgin interfaces file here (actually, a copy before I made any changes) doesn't have it. That's from pukka Debian running on an RPi rather than Raspbian, I can't remember where I saw the comment that it was now optional (albeit harmless) and my usual practice is to put it in when I set up static addresses etc. I've just fired up a known-good RPi3 on a 3A PSU with Stretch 2017-09-07, and I think there's something fundamentally wrong: no display on HDMI, That I've had all along, from the first powerup. There's 3 or 4 threads about that on the forum that I need to re-read. But I get the impression most are winders escapees, if they say they've fixed it, they never give a clue as to HOW they fixed it. Frustrating to a new reader. I experimented with the same RPi a couple of weeks ago connected to a DVI port on an NEC Multisync, and got a display. However today it certainly wouldn't talk happily to a dedicated HDMI Philips monitor... I lack the time to investigate in any depth and I've put so much time into trying to get these things to work with "unusual" HDMI-connected devices that I don't have much inclination either. but capslock on the keyboard toggles as expected. Thats from the batteries in the keyboard if its wireless. My logitech k-360s caps lock indicators work when they are out of radio reach. Wireless? /Wireless?/ Wash your mouth out. Classic IBM PS/2 keyboards don't /do/ wireless, and neither do I when I can possibly avoid it. But that brings up a question: How do I give a machine a known name, so even if its address changes with the next connection, I can still login to it by that machine name? I am so used to static addresses, I never learned how to make dhcp work transparently. We tend to use a lot of static addresses and hardcoded DNS names around here, which in part reflects the "maturity" of our overall system. However these days, if you have an e.g. ISC DHCP and DNS server on a "nearbu" system they can update each other... this is something that I've had working and is pretty much SOP but there's no way I'd call myself practiced and competent to talk you through it :-) Now, I'd better go refill the missuses coffee cup and see what she wants for breakfast. She's a skinny thing, no padding, fell and busted a hip back in February, has COPD too so she's not getting around very good. So I'm doing it all. Look after yourselves. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: need sd card backup on r-pi-3b
On 25/09/17 03:15, Gene Heskett wrote: On Sunday 24 September 2017 17:50:22 Alan Corey wrote: Try putting your static route in interfaces, in the eth0 section with an up, like iface eth0 inet static address 192.168.71.3/24 netmask 255.255.255.0 up route add default gw 192.168.71.1 I think post-up might be too late, maybe there's a pre-up. post-up works reliably here, and I'm doing a lot of router stuff on them- but based on Jessie, and typically on pukka Debian rather than Raspbian. Whatever, didn't work either, so I was trying "variations on a theme" and locked myself out, so I pulled on some slippers and fished a light out of my pocket, opened the fire door out of the bedroom and padded across the back deck to the garage, to be greeted by the monitor showing me an x login. Neat, but no response from the keyboard or mouse. Reset it several times to no avail. ISTR seeing something about x killing the usb power on the forum. I can see the effect of keypresses while the boot msgs are scrolling by, so that forum msg now makes sense. Might have to round up a bigger psu, its running on a pi supply rated at 2.5 amps, mini-wall-wart type. I've got a bigger one lounging about in that midden heap, a meanwell perforated box rated at 3, maybe 4 amps. So I'll stick the card back in a reader tomorrow, see if I can find that eth0 file and remove my last variation, which was "pre-up" IIRC. If that kills the x login, then Houston, we have a problem. :) Twon't be the first time I've had to backtrack. :) Sigh... There is another possibility, ifconfig shows a lo interface but there isn't any such starter file! There is an lo stanza on the jessie/pi. So one of my experiments will be to compose one, just for S&G. Steal it out of the pi's jessie file. Yeah, valid experiment that. I believe lo is now inserted automatically. I've just fired up a known-good RPi3 on a 3A PSU with Stretch 2017-09-07, and I think there's something fundamentally wrong: no display on HDMI, but capslock on the keyboard toggles as expected. This is definitely not something I can put substantial time into ATM, but I think there's a possibility of e.g. things being broken if there's no visible DHCP server. Best I can suggest for the moment is keeping a close eye on the forum, since I think this is an Raspbian issue rather than more general Debian. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: need sd card backup on r-pi-3b
On 24/09/17 19:45, Gene Heskett wrote: I wouldn't put the manual route command in rc.local, I'd put it in the network interface definition as in allow-hotplug eth0 iface eth0 inet static address 172.27.200.5/24 post-up route add default gw 172.27.200.1 dev eth0 metric 0 pre-down route del default gw 172.27.200.1 dev eth0 Printed to carry out to it, rc.local didn't work at all. I'll try this next Thanks. Didn't work, with my addresses, it gave me an empty route -n report. Back to doing it by hand after a reboot. Now trying to get X11 started. X server not in path. :( There's something badly wrong there. Run ifconfig -a to check that your interfaces are named as expected. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: need sd card backup on r-pi-3b
On 24/09/17 16:30, Gene Heskett wrote: On Sunday 24 September 2017 11:59:57 Alan Corey wrote: But what's the purpose of having the gateway fields in interfaces if not to to be reliant on the routing table? But it's worth a shot, something like route add default gw 192.168.71.1 That was it! Now I've used apt to update 5 packages, and its now installing synaptic and all its 2nd and 3rd cousins. 112 megs worth. I did ask it to install xfce, but it couldn't find it. I'll try lxde next, but its entirely too simple. With xfce I can set up 4 workspaces/windows and the survive a reboot. You can add them in lxde, but they don't survive a reboot. Anyway, progress, sorta. I am going to put that command in rc.local just for S&G. Oh, oh, I had to create that file, does not bode well. But we'll find out I guess. Is there something in the /etc/network/interfaces file which is preempting what's in your .d directory? I wouldn't put the manual route command in rc.local, I'd put it in the network interface definition as in allow-hotplug eth0 iface eth0 inet static address 172.27.200.5/24 post-up route add default gw 172.27.200.1 dev eth0 metric 0 pre-down route del default gw 172.27.200.1 dev eth0 Even assuming that Network Mangler isn't being used, a mis-parse would not surprise me. I really can't remember the detail but I've previously come across some combination of packages which broke each other badly (something like multiple gateways breaking VLAN support). Apropos different window managers (AKA desktop, environment etc.), a lot depends on what display manager (AKA login screen) is being used. For various reasons we favour lightdm, which generally speaking picks up the available window managers. Apropos locales, my setup notes for putting Debian onto an RPi have ! dpkg-reconfigure tzdata ! ! apt-get update and upgrade here. Install locales (ALREADY DONE) and ! console-setup and run dpkg-reconfigure locales console-setup and ! keyboard-configuration using physical console just in case... it's ! probably better to MOVE THIS EARLIER since apt-get upgrade warns ! about some LANG etc. settings that haven't yet been established. You can see what packages are installed using something like dpkg --get-selections -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: need sd card backup on r-pi-3b
On 23/09/17 20:00, Gene Heskett wrote: So my local network is working as expected. BUT: root@rock64:/etc# ping -c1 yahoo.com PING yahoo.com (98.138.253.109) 56(84) bytes of data. From 192.168.71.2 (192.168.71.2) icmp_seq=1 Destination Host Unreachable Note that the dns request did resolve. But my dns requests are probably being answered by dnsmasq in the router. I cannot find anything in the routers copious settings (it's DD-WRT) that would prevent a connection, but it refuses to pass. I've tried several ipv4 addresses in that 192,168.nn block. No other machines, 5 more, on this local net are being denied network access. Ideas? I'm nearly out of hair. But its been slowly thinning for 82+ years too so I can't blame it on this too loudly. I've only run Stretch briefly so far, in the context of trying to find out whether USB boot worked (patchy, but might have been a power issue). I'd suggest checking using traceroute -I and then looking at route -n and/or ip route ls which should give you a bit more of an indication of what's going on. IME this sort of thing is usually because the router isn't NATting the entire 192.168.x.x range. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: need sd card backup on r-pi-3b
On 23/09/17 16:45, Gene Heskett wrote: On Saturday 23 September 2017 12:26:23 Mark Morgan Lloyd wrote: On 23/09/17 15:00, Gene Heskett wrote: I've never had problems with dd provided that the USB->SDcard adapter's OK: what command are you using? The usual syntax: dd if=somefile bs=512 of=somedevice, and in the case of sd card copying, Tell us the /exact/ command you're using. since no 2 are alike so I usually look at the src's declared size in dmesg and set count=that-5k so it doesn't error out copying a pny 32GB to a Sandisk 32GB. Etcher, which is faster, has the same problem & pitches a fit when it can't find room to put the last 10 sectors. I've had poor luck with sandisk anything though. pny, samsung is good stuff. So I bought pny last night. The first thing I'd say is that almost all of the problems I've had stopped when I changed the card reader. I'm now using one badged Canyon which specifically has a Micro-SD slot, i.e. I'm no longer trying to use an adapter which is universally regarded as being unwise. I have 2 vivitar's, both with microsd slots. They work 100% when burning an image file from armbian jessie so far. You don't need that bs=512 and trying a sector-by-sector copy on a device that uses far larger blocks might be unwise. I use bs=128M I'll give that a shot. Don't give dd an explicit block count, let it copy everything. That 5k in particular could be worse than useless since it doesn't correspond to a physical or logical block size. no two sd cards, even from the same maker, are exactly the same size due to bad block replacements before they are even blister packed for sale. This is the exact reason they ship stripped images that require you resize them on the machine they will live in. What we dearly need is a utility to generate the iso shrunken to only that which is actually used. Or do we have such a critter and I don't know about it? I know all that, and I've spent a lot of time talking to these things directly, measuring times, checking pattern-sensitivity and so on. And I'd remind you that while we're using similar hardware, you're having problems, I'm not. What does that suggest to you? :-) Zeroing the target device first might help, i.e. copying from /dev/zero If the source device has been partitioned to be full, then shrink first the top filesystem and then the top partition to make sure that what you're copying is substantially smaller than the target device. Alternatively a useful hack is to set up your source device with an extra partition at the top, e.g. FAT just in case you want to move data around between OSes, then you can delete the top filesystem and partition before using dd and be confident that you won't be doing an incomplete copy. Seems like something that could be scripted. Yes, for example by the script that Raspbian runs on its first startup. Don't fool around, just make sure that the valid data on the source card is substantially smaller- and I mean 100s of Mb, not a few Kb- than the destination card. But my suspicion is that you're doing something wrong like trying to copy one partition when you should be copying all partitions. But since you won't give us an example of the command you're using we can't be certain either way on that. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: need sd card backup on r-pi-3b
On 23/09/17 15:00, Gene Heskett wrote: I've never had problems with dd provided that the USB->SDcard adapter's OK: what command are you using? The usual syntax: dd if=somefile bs=512 of=somedevice, and in the case of sd card copying, Tell us the /exact/ command you're using. since no 2 are alike so I usually look at the src's declared size in dmesg and set count=that-5k so it doesn't error out copying a pny 32GB to a Sandisk 32GB. Etcher, which is faster, has the same problem & pitches a fit when it can't find room to put the last 10 sectors. I've had poor luck with sandisk anything though. pny, samsung is good stuff. So I bought pny last night. The first thing I'd say is that almost all of the problems I've had stopped when I changed the card reader. I'm now using one badged Canyon which specifically has a Micro-SD slot, i.e. I'm no longer trying to use an adapter which is universally regarded as being unwise. You don't need that bs=512 and trying a sector-by-sector copy on a device that uses far larger blocks might be unwise. I use bs=128M Don't give dd an explicit block count, let it copy everything. That 5k in particular could be worse than useless since it doesn't correspond to a physical or logical block size. Zeroing the target device first might help, i.e. copying from /dev/zero If the source device has been partitioned to be full, then shrink first the top filesystem and then the top partition to make sure that what you're copying is substantially smaller than the target device. Alternatively a useful hack is to set up your source device with an extra partition at the top, e.g. FAT just in case you want to move data around between OSes, then you can delete the top filesystem and partition before using dd and be confident that you won't be doing an incomplete copy. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: need sd card backup on r-pi-3b
On 23/09/17 05:45, Gene Heskett wrote: Months at a time here, but anytime I need to do anything as root that involves more than ncurses graphics, I have to go to the machine and do it there, and its a stand-up job with very poor gfx due to the pi's In that case investigate what's stopping you from logging in directly as root. It's probably a setting in sshd_config and another in the display manager's configuration file. Otherwise if you've got an SSH session as non-root you should be able to run arbitrary non-root X11 programs over it i.e. tunelling/forwarding X11 over SSH. Once that is working, you should be able to use a desktop-specific graphical variant of sudo to run a program as root: in the case of KDE it's kdesudo. Or alternatively, in an SSH session try sudo -E someprogram which works in many cases. I've never had problems with dd provided that the USB->SDcard adapter's OK: what command are you using? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Is this the right list to discuss Debian problems on pinebook?
On 12/09/17 17:15, Andreas Tille wrote: In short: Is this the right list for this kind of questions or should I rather ask this on pine64 forum. We're interested and sympathetic, but like things such as the Raspberry Pi a lot depends on the extent to which the hardware manufacturer makes sure that upstream developers are aware of what he's doing. I would say that for the last couple of years I've been running pukka Debian on Raspberry Pis, updating the kernel on a fairly regular basis by having a minimal Raspbian partition to oversee downloading kernel and bootloader into /boot. The thing to note in this case is that you also have to copy the appropriate tree from Raspbian (or whatever) /lib/modules onto the Debian root. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: ARM Ports BoF: armel in buster
On 28/08/17 09:30, John Paul Adrian Glaubitz wrote: On 08/28/2017 12:53 AM, Paul Wise wrote: OTOH the only relevant hardware for armel these days seems to be RPi, so why not make armel into armhfv6 instead? Aren't most RPi users running Raspian anyway which is armhf with -march set to ARMv6? Bumping armel from soft-fp to ARMv6 hard-fp doesn't seem to make much sense to me though. For the record, we're running pukka Debian on top of the Raspbian Jessie kernel etc. on roughly a dozen RPis here. We found that to be the preferable combination since we needed KDE and found that it didn't play nicely with the Raspbian display subsystem, although we might reconsider that now that Raspbian "Stretch" is available. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: sshfs failure
On 12/08/17 00:15, Gene Heskett wrote: On Friday 11 August 2017 13:56:16 Jens Thiele wrote: try to ssh with -v to get more info: gene@coyote:~$ ssh -v pi@picncsheldon jens Maybe, but I have 2 copies of bash, terminal-4.8, and all those logins are working flawlessly. I'd expect new but not existing connections to fail if a security update has deprecated a key size or type but the daemon hasn't been restarted to pick it up. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: pi vs swap on flash
On 13/07/17 16:15, Alan Corey wrote: Mine looks like: etc. Yes, agreed. You might also need to tell it to stop using a file on the normal filesystem as swap- to be honest I can't remember how to do that. It's worth remembering that swapon -s will tell you what partitions and files are being used. But the bottom line is that the RPi is trying to push all I/O through limited bandwidth, and if you want decent performance it's probably not the best board to use. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: advice on Raspberry Pi and alternatives?
On 06/07/17 08:00, Daniel Pocock wrote:
Hi all,
There has been some discussion[1] on the OpenAg forum about problems
between Raspberry Pi, Arduino and rosserial
They are reviewing their architecture and potentially eliminating
Arduino and I suggested[2] they consider following a strategy where
people can use alternatives to Raspberry Pi, because of the binary blob
needed at boot and also because it just seems smart to have some
flexibility.
Can anybody make any practical suggestions?
The Debian wiki[2] has a list of possibilities, but which alternatives
are best supported by Debian / Raspbian if somebody was starting today?
1.
http://forum.openag.media.mit.edu/t/rosserial-tool-avrdude-build-failing-with-not-matching-sha/1774/16?u=pocock
2. https://wiki.debian.org/RaspberryPi
Allowing that this is a Debian ML rather than a Raspbian forum, are
there still blocking issues for a headless ("Lite") distro which doesn't
require local video etc.?
For headless operation, is the situation the same for both 32- and
64-bit variants of the distro?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Re: piclone needs "blank" sd card.
On 17/06/17 18:00, Gene Heskett wrote: Greetings all; All i/o options in piclone are ghosted. The help says it wants a blank sd card. How it this accomplished if piclone has attempted to use it previously and it contains week old non-precious data? Is it sufficient to wipe out the GPT partition table with dd using 20k worth of /dev/zero? I'm concerned that might wipe out the card totally. I have no reason to believe that dd can damage a card. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: What is the recommended armhf disk partitioner for use on rotating media?
On 17/06/17 15:45, Gene Heskett wrote: On Saturday 17 June 2017 10:24:11 Mark Morgan Lloyd wrote: On 17/06/17 14:15, Gene Heskett wrote: Greetings all; See subject, on an rpi3b running raspian/jessie. I have a terabyte usb drive plugged in, and I want to set up an rsync cron job to backup the sd card to this drive and I need to reset the /dev/sda1 file system to vfat, which it is not ATM. Use fdisk to change the type to b or c and then mkfs.vfat to reformat it. Note however that Flash-based media might have the first partition start at a specific block since one of the early blocks has slightly different properties in order to accommodate frequent FAT updates, so if you know how the device was partitioned at the factory it's worth restoring to that if possible. Its been re-partition with gparted, 2 or 3 times. IIRC there is a small space, to align it or whatever in front of /dev/sda1. fdisk has a longer and whiter beard than I do, and I wasn't aware it had been to school to learn the new partition schemes? There's lots of different fdisk implementations. On PC-like systems it was originally supplied by the hardware manufacturer i.e. Zenith or Compaq's fdisk wasn't quite the same as IBMs. fdisk is installed and seems to recognize everything including a 2048 (sectors?) gap in front of sda1. Perhaps thats pristine yet? https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey plus the link bear the top. I've spent a lot of time extracting speed info from SDCard tests over the last couple of months, and can confirm that there /are/ differences in the way that the first few blocks are set up. I've not yet extended this to "stick" devices, and I don't think it's of Earth-shattering importance for devices which are only going to be used for occasional writes and isn't at all relevant if a device is being reformatted as e.g. ext4. What I can say that is relevant to most people running RPis or anything else which uses an SDCard is that with certain access patterns I was able to get a reproducible glitch of roughly 500 mSec while the card handled block erase etc. I suspect that it's power loss during that 500 mSec, which might extend beyond OS shutdown, that's resulted in people suddenly finding they'd got a dud card. So the rsync source is the sd card, and the target is this hard drive. Does this warning still apply? I did a t[return], l[return[ but do not see the desired vfat listed as a choice. Is it a synonym for something else? apropos fsck and then look at the manpages it lists. OTOH, one should file a bug against fdisk as the description string is printed at a reduced width, losing valuable information about the individual filesystem to use on a given partition. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: What is the recommended armhf disk partitioner for use on rotating media?
On 17/06/17 14:15, Gene Heskett wrote: Greetings all; See subject, on an rpi3b running raspian/jessie. I have a terabyte usb drive plugged in, and I want to set up an rsync cron job to backup the sd card to this drive and I need to reset the /dev/sda1 file system to vfat, which it is not ATM. Use fdisk to change the type to b or c and then mkfs.vfat to reformat it. Note however that Flash-based media might have the first partition start at a specific block since one of the early blocks has slightly different properties in order to accommodate frequent FAT updates, so if you know how the device was partitioned at the factory it's worth restoring to that if possible. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: keyboard config for english UTF-8
On 21/05/17 21:20, Gene Heskett wrote: Greetings; I just spent 2 hours trying to get std US keyboard response out of PI. The closest I have gotten so far are the correct characters about the numerals on the top row. But I'll be switched if I can get single and double quotes out of the key left of the enter key. I have to hit the key twice for either, but the resultant dots are tiny and for sure aren't recognized as quotes, single or double. ISTR I had to edit a file in the /etc directory to get an english_US-UTF-8 keyboard quite some time back. And trying to do that with a root session of raspi-config is a waste of everybodies time. So, which side of my mouth am I supposed to be holding a chew of Kentucky Twist to make the raspi-config capable of fixing this CORRECTLY for an en_US-UTF-8 setup. Exactly none of the generic keyboards listed seem to have the desired effect if any. Thanks for any help I can paint on the wall for when I have to build/rebuild another sd card. Be warned that this might break subsequent use of raspi-config, but have you tried either of dpkg-reconfigure locales dpkg-reconfigure console-data -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: this mornings update bricked my pi.
I agree, with the caveat that not all adapters are created equal. We've got some branded "Canyon" which take both full-sized and Micro SDCards, and their performance is much better- in terms of both speed and reliability- than older ones. http://canyon.eu/product/cne-card2/ I'd also warn people to be /very/ careful with any RPi case that doesn't fasten the board down well, I've managed to physically crack two cards by getting them wedged against the edge of the slot: I'm not naturally hamfisted and aren't happy about it. And those cards were flashing once or twice at boot... On 02/05/17 13:30, Alan Corey wrote: Hmm, only 1 Pi and 1 SD card? Got a reader for the SD card you can use to fsck the card in another Linux box? Heck, you should be able to mount it and do stuff to it. Might be able to find a reader at a photo place. On 5/2/17, Gene Heskett wrote: It flashes the green led 3 or 4 times in the first second of powerup, and dead, so I assume the sd card is now trashed. This was rasbian, running a special pre-empt-rt kernel. Where can I find some help? Thanks. 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> -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: question on armhf color depth
On 10/04/17 10:30, Gene Heskett wrote: On Monday 10 April 2017 04:55:39 Mark Morgan Lloyd wrote: On 10/04/17 02:30, Alan Corey wrote: I think you can add entries to /etc/fb.modes but it's like making old-style modelines, it takes lots of information. And my old buddy xvidtune doesn't work on a Pi. But you're a tv guy. Video modes have been causing me a great deal of pain over the last few weeks. I could say much more but will keep it short with just two comments to start with: * Look at what's in your X log file and at /sys/class/graphics/fb0/modes (should apply to most systems that use standard video). pi@raspberrypi:~/linuxcnc $ cat /sys/class/graphics/fb0/modes U:1366x768p-0 pi@raspberrypi:~/linuxcnc $ From the log: [12.657] (WW) Falling back to old probe method for modesetting [12.657] (EE) open /dev/dri/card0: No such file or directory [12.657] (WW) Falling back to old probe method for fbdev -- [12.780] (II) AIGLX: Screen 0 is not DRI2 capable [12.780] (EE) AIGLX: reverting to software rendering [14.243] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer How can these be fixed? The video's update rate sux. You'll need to check with somebody who knows the specific RPi/Raspbian situation. I suspect it will require non-free drivers... and that's non-free as in beer as well as speech. * Use tvservice to get EDID info from your screen and feed it to edid-decode (systems other than RPi will have some different means of getting the binary EDID block, e.g. an Odroid uses a modified U-Boot). It's obviously important though to distinguish between resolution/sync configuration and the colour depth, the latter being largely determined by available memory. And 128 megs is not enough for 32 bit apparently. It (24 bit) also slows rendering speed noticably. Stop flailing around and get the EDID info to see what refresh rate the screen will offer for any given resolution. Then start off at 16 bits, try to get that working, and then try 24. The best I can get at 3840x2160 (?) is 24 fps from an RPi3. 16 bit video is OK, 24-bits is marginal (I suspect a problem with mouse pointer etc. code), 32 bits has a major impact on system stability (i.e. length of time it will run before it's using swap). HDMI is designed around a 24-bit data stream and I don't know to what extent trying to use 32 confers any advantage, and there's some unpleasant maximum pixel rates etc. to contend with. In principle it should be possible to tune the RPi modeline to emit sync rates etc. that don't exceed the limitations of the clock rate, in practice we've had no success with that yet but I'm still to start playing with full modelines... note that modeline format is not the classic XFree86 one. In practical terms the video capabilities of an Odroid C2 are substantially better, even if their Ubuntu-derived UI sucks and they've got package dependency problems. I don't know to what extent that indicates an inherent superiority of the Odroid's Mali graphics subsystem over the RPi's Broadcom one, or whether it's fair to say that the developer community understands Mali better that Broadcom, or if it's just me drawing some wrong conclusions. The driving force at this end is a colleague with sight problems who can only handle a spreadsheet etc. with a large fount and screen. Since very often I'm in the position of trying to set up his computer remotely when he's plugged it into an HDMI TV I've never seen I'm not exactly enjoying the experience. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: question on armhf color depth
On 10/04/17 02:30, Alan Corey wrote: I think you can add entries to /etc/fb.modes but it's like making old-style modelines, it takes lots of information. And my old buddy xvidtune doesn't work on a Pi. But you're a tv guy. Video modes have been causing me a great deal of pain over the last few weeks. I could say much more but will keep it short with just two comments to start with: * Look at what's in your X log file and at /sys/class/graphics/fb0/modes (should apply to most systems that use standard video). * Use tvservice to get EDID info from your screen and feed it to edid-decode (systems other than RPi will have some different means of getting the binary EDID block, e.g. an Odroid uses a modified U-Boot). It's obviously important though to distinguish between resolution/sync configuration and the colour depth, the latter being largely determined by available memory. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Testing boot loaders
On 01/03/17 15:00, Lennart Sorensen wrote: On Wed, Mar 01, 2017 at 08:57:15AM +, Mark Morgan Lloyd wrote: Yes, I agree. What I don't know yet is whether there's a comparatively straightforward way to copy the loader (plus its header etc.) into the appropriate area of Qemu's address space and then transfer to it. Ideally after that there would be enough startup messages to indicate that the kernel was running, even if there wasn't emulated framebuffer hardware. I think that the latest Qemu might have MX50 support, but at this stage it's the initial boot that's interesting. Hmm, all I had seen was MX25. Looking at the git tree I see 25, 31 and 6, but no 5x. Is this relevant? It's come via Android but does appear to have hardware definitions. https://github.com/esminc/qemu/tree/master/Source/device-qemu/android/android-goldfish-3.4/arch/arm/mach-imx u-boot code would not be likely to do much for you if qemu doesn't emulate the machine u-boot was compiled for. I have no idea how hard adding a new machine to qemu would be. Neither have I, and my attempts to understand Qemu code generation haven't been very successful so far. However I think the current problem boils down to (a) how do we get the loader code into the right bit of memory and (b) how do we trace through that, at least until we find unimplemented hardware? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Testing boot loaders
On 28/02/17 21:30, Lee Fisher wrote: On 02/28/2017 11:38 AM, Mark Morgan Lloyd wrote: [...] Is it possible to use Qemu or some comparable emulator to check the boot sequence in situ, i.e. without breaking the U-Boot and kernel images out into separate files? There are a few tools which take embedded Linux/Android disk images, run QEMU to emulate the missing hardware, and then attack it with whatever they can. Maybe one of those tools can help you with your boot sequence needs? Below are a few, there are others that I'm forgetting the names of, these will probably help you search for the ones I'm forgetting. :-) Sorry, unsure if there is an option that will work with U-Boot and Debian and ARM. (I haven't worked much with these tools, instead focus on UEFI/ACPI 'blobs'.) https://firmwaresecurity.com/2016/02/28/firmadyne-automated-analysis-of-linux-embedded-firmware/ https://firmwaresecurity.com/2015/09/23/costins-embedded-firmware-security-thesis/ https://firmwaresecurity.com/2015/11/23/panda-vm/ https://firmwaresecurity.com/2016/08/25/firminator/ https://firmwaresecurity.com/2016/02/28/firmadyne-automated-analysis-of-linux-embedded-firmware/ You might also try asking on Twitter, on the firmware-security list. https://twitter.com/JacobTorrey/lists/firmware-security https://firmwaresecurity.com/2017/01/17/firmware-security-list-on-twitter/ Also, I've not tried it for this purpose, but perhaps S2E/Avatar has some features that might help you. http://www.s3.eurecom.fr/tools/avatar/ Thanks Lee, I'll follow those up. As an initial hack I think I can graft in Debian by breaking into the init sequence early. Kernel -> init -> /etc/init.d/rcS, and if I remount / onto an external device right at the start of that I should have full control. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Testing boot loaders
On 28/02/17 22:30, Lennart Sorensen wrote: On Tue, Feb 28, 2017 at 07:38:28PM +, Mark Morgan Lloyd wrote: I wonder whether I could ask a general question, with a particular focus on Debian ARM devices. I've got in front of me a file containing the image of an SD-Card that I've exfiltrated from a Kobo ereader onto which somebody wants me to put Debian. It appears to have a common or garden partition table at the start, live and recovery filesystems, and then a large storage area: Device Boot Start End Sectors Size Id Type kobo.bin1 49152 573440 524289 256M 83 Linux kobo.bin2573441 1097729 524289 256M 83 Linux kobo.bin3 1097730 7744511 6646782 3.2G b W95 FAT32 I believe that there's a configured copy of U-Boot and the kernel in the unpartitioned area at the start of the device, there isn't any jump code in the partition table. The device is based on the "Freescale MX50 Reference Design Platform", and kernel sources etc. are available on Github, I think I can see that the boot loader's entry is at 0xF8006458. Is it possible to use Qemu or some comparable emulator to check the boot sequence in situ, i.e. without breaking the U-Boot and kernel images out into separate files? Well in case you don't know, at least on the i.MX51 the boot code is at offset 1024 bytes from the start of the device (so slightly after the partition table). I suspect the i.MX50 probably does the same, so the u-boot or other boot code should be found between 1K and the start of the first partition. Yes, I agree. What I don't know yet is whether there's a comparatively straightforward way to copy the loader (plus its header etc.) into the appropriate area of Qemu's address space and then transfer to it. Ideally after that there would be enough startup messages to indicate that the kernel was running, even if there wasn't emulated framebuffer hardware. I think that the latest Qemu might have MX50 support, but at this stage it's the initial boot that's interesting. My guess would be .bin1 and .bin2 are primary and backup system partitions, with the FAT32 purely for ebook storage and exposed as a disk when a USB connection to another machine is made. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Testing boot loaders
I wonder whether I could ask a general question, with a particular focus on Debian ARM devices. I've got in front of me a file containing the image of an SD-Card that I've exfiltrated from a Kobo ereader onto which somebody wants me to put Debian. It appears to have a common or garden partition table at the start, live and recovery filesystems, and then a large storage area: Device Boot Start End Sectors Size Id Type kobo.bin1 49152 573440 524289 256M 83 Linux kobo.bin2573441 1097729 524289 256M 83 Linux kobo.bin3 1097730 7744511 6646782 3.2G b W95 FAT32 I believe that there's a configured copy of U-Boot and the kernel in the unpartitioned area at the start of the device, there isn't any jump code in the partition table. The device is based on the "Freescale MX50 Reference Design Platform", and kernel sources etc. are available on Github, I think I can see that the boot loader's entry is at 0xF8006458. Is it possible to use Qemu or some comparable emulator to check the boot sequence in situ, i.e. without breaking the U-Boot and kernel images out into separate files? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: missed keystrokes problem, back with a vengeance.
On 30/01/17 23:00, Alan Corey wrote: Biscuit tin or similar would do, ocuple of large ferrite cores and wind the usb cables toroidally? One question I've had for years about using big toroids for suppression is this: If you've got a cord that you don't want to take the connector off to fit through the toroid, does it do the same amount of good to just double a few feet of it back on itself and feed that through the toroid? Or do the magnetic fields oppose each other because the currents are flowing in opposite directions? You can get split toroids (i.e. two C-shaped lumps) that are held together with a plastic shell, specifically for retrofitting to troublesome kit to bring it in line with required levels of emission and sensitivity. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: missed keystrokes problem, back with a vengeance.
On 29/01/17 14:00, Gene Heskett wrote: Greetings everybody; I am in the process of bringing a nearly 70 yo Sheldon lathe back to life, useing an raspberry-pi 3b for the machine controller. However, I have now had 5 different keyboards plugged into it, some wired, some wireless, and none of them can give me a dependable response to a key, and the error seems much worse for the key-up event. When driving the machine by hand as we often do for one-offs, missing a keyup event can be disastrous for the part being made because it keeps on cutting until you've given that, or another key, a quick tap to stop the unwanted motion. There is something funkity in the usb keyboard handling that can get much worse with a reboot, or get almost perfect with a reboot. Its all uptodate a/o yesterday. The psu is a 4 amp box, making 5.07 volts solidly. Verified with a 100 Mhz scope. I think that the first thing I'd suggest is that you set up a program to blink an LED on one of the GPIO ports, so that you can be absolutely certain that it's not the entire RPi going to sleep. I've not seen that sort of problem on the RPi3 that I'm using as a desktop system, but what I've got here is unusual in three respects. The first is that it's not running Raspbian: it's booting a Raspbian-supplied kernel and has the matching modules, but the remainder is pukka Debian. The second is that I'm using a high-quality IBM "Classic" keyboard via a reasonable USB converter. I've had to fix dud joints in two USB keyboards for a colleague. The third is that / is a rotating disc (Seagate notebook accessory), so isn't susceptible to the pauses that- as I understand it- at least some SD-Cards can inflict on a system while they shuffle blocks around. I /do/ see a delayed UI response on occasion, but I put that down to KDE and/or X11 gradually claiming an excessive amount of memory. I'm not aware of completely missed events. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: xset +dpms is not controlling monitor powerdown on raspberry pi 3b
On 10/01/17 19:30, Alan Corey wrote: In Wirth's history it was Pascal, Modula, Oberon I think. I learned Pascal on a VAX and an Apple 2 at the same time for an Apple 2 project, skipped Modula (and Ada), played with Oberon some. Borland's Turbo Pascal screamed, I wrote a lot of Delphi too. Lazarus suffers from having too many authors, it's too disorganized. Borland undercut everybody on price I think, Turbo Pascal started at something like $30 when everybody else was charging $200+? I remember seeing some APL but FORTRAN seemed more useful. I think I only knew 1 person who used APL. APL does have a certain geek appeal, but the weirdness of its right-to-left evaluation order makes the character set issues look trivial. FWIW I've never owned a Microsoft mouse, always Logitech. Never paid money for a Microsoft product period. We had to buy a lot of MS and IBM stuff when we bought the rights (i.e. source etc.) of what would today be called a SCADA package. I ended up rewriting from scratch in Delphi, while I do quite a lot using FPC+Lazarus I've never ported that stuff. Desperately trying to keep somewhat on-topic: Lazarus does a pretty good job of being what 30 years ago we'd have called a 4GL, with a drag-and-drop form builder, database access and the rest. However I'd like to salute one specific MS product: Visual Basic for DOS. If there had been anything comparable to that (or to one of the 4GLs such as dbXL or whatever) using Curses on Linux it might really have made a difference to the extent to which it was adopted. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: xset +dpms is not controlling monitor powerdown on raspberry pi 3b
On 10/01/17 19:30, Lennart Sorensen wrote:
On Tue, Jan 10, 2017 at 06:43:57PM +, Mark Morgan Lloyd wrote:
I've just managed to rescue a bunch of Logitech compiler manuals (I've
recently had to sacrifice a lot of old stuff) with the hope of at least
getting a photo of their early products into Wp to keep the knowledge alive.
The v3 copyright notices start off at 1984 (v2 might have earlier dates but
I can't see where I've put it), and I am pretty sure that that predates
their mice; my recollection is that Mouse Systems and "PC Mouse" which might
or might not have been distinct had the market to themselves in the earliest
days.
Well they were doing mice in 1982 along with some gui editor. I think
The editor was probably Point, it was really quite good and had
(undocumented) expansion capabilities.
modula-2 and debuging came in 1983. Selling mice by themselves seem to
have been a couple of years later, whenever the C7 came out, although
they were selling mice to Apollo and HP before that. Not sure if they
also supplied Sun or if that was someone else, although given it was
optical, probably someone else.
Thanks for that timeframe. I've definitely seen Mouse Systems mice on
Apollo and Sun and Wp has a photo for the latter.
Logitech started to walk away from compilers and concentrate on peripherals
when they bought a small company (AMS?) in Warrington ("where the wodka
comes from") that made mice etc. for the likes of Amstrad computers, AIUI
they also had... errm... personnel problems which effectively resulted in
their shutting down the UK office (a nicely-appointed tithe barn somewhere
in the Home Counties, possibly Berkshire but I forget the exact location).
Of course, Logitech's M2 was challenged by JPI/Topspeed which was bought out
of Borland. legend had it that Borland effectively sabotaged the 8-bit
variant by retaining the manual copyright and refusing to reprint, but the
16-bit variants did fairly well for a while until they had... errm...
personnel problems in their USA office which effectively forced them to sell
out to Clarion.
I supported the Logitech compiler being used for embedded '186 work at
Lowbrow Uni in the mid-80s, and later did a fair amount of embedded work
using TopSpeed (bare-metal '286 code). These days of course one would use
ARM for comparable jobs, with or without a standard OS.
Yeah lots of options today.
Borland and Watcom and such all seem to have died out by now.
I think that at least some of the Watcom stuff is open-source now.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Re: xset +dpms is not controlling monitor powerdown on raspberry pi 3b
On 10/01/17 17:30, Lennart Sorensen wrote:
On Tue, Jan 10, 2017 at 08:17:59AM +, Mark Morgan Lloyd wrote:
On 09/01/17 22:00, Gene Heskett wrote:
On Monday 09 January 2017 10:52:46 Mark Morgan Lloyd wrote:
Logitech should have stuck to selling compilers.
Thats a different company I believe.
Same company, I was their de-facto UK tech support for a while. Long
predated Linux of course (in a nod to the fact that we're wandering way OT).
Logitech made software and mice right from the start, and only got into
compilers (module-2 I believe) a bit later (although not very much later
it seems)
I've just managed to rescue a bunch of Logitech compiler manuals (I've
recently had to sacrifice a lot of old stuff) with the hope of at least
getting a photo of their early products into Wp to keep the knowledge
alive. The v3 copyright notices start off at 1984 (v2 might have earlier
dates but I can't see where I've put it), and I am pretty sure that that
predates their mice; my recollection is that Mouse Systems and "PC
Mouse" which might or might not have been distinct had the market to
themselves in the earliest days.
Logitech started to walk away from compilers and concentrate on
peripherals when they bought a small company (AMS?) in Warrington
("where the wodka comes from") that made mice etc. for the likes of
Amstrad computers, AIUI they also had... errm... personnel problems
which effectively resulted in their shutting down the UK office (a
nicely-appointed tithe barn somewhere in the Home Counties, possibly
Berkshire but I forget the exact location).
Of course, Logitech's M2 was challenged by JPI/Topspeed which was bought
out of Borland. legend had it that Borland effectively sabotaged the
8-bit variant by retaining the manual copyright and refusing to reprint,
but the 16-bit variants did fairly well for a while until they had...
errm... personnel problems in their USA office which effectively forced
them to sell out to Clarion.
I supported the Logitech compiler being used for embedded '186 work at
Lowbrow Uni in the mid-80s, and later did a fair amount of embedded work
using TopSpeed (bare-metal '286 code). These days of course one would
use ARM for comparable jobs, with or without a standard OS.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Re: xset +dpms is not controlling monitor powerdown on raspberry pi 3b
On 09/01/17 22:00, Gene Heskett wrote: On Monday 09 January 2017 10:52:46 Mark Morgan Lloyd wrote: Logitech should have stuck to selling compilers. Thats a different company I believe. Same company, I was their de-facto UK tech support for a while. Long predated Linux of course (in a nod to the fact that we're wandering way OT). I want an APL keyboard. One of those controlling CAM kit would be decidedly cool :-) APL? Not fam with that acronym. https://en.wikipedia.org/wiki/File:APL-keybd2.svg https://en.wikipedia.org/wiki/APL_%28programming_language%29#Syntax Weird by today's standards, but has its uses and there's implementations that run on Debian ARM etc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: xset +dpms is not controlling monitor powerdown on raspberry pi 3b
On 09/01/17 15:00, Alan Corey wrote: 1860NX). So even if ones budget doesn't run to an HDMI monitor or TV, there's a fair number of these on eBay. The best deal on a cheap HDMI monitor I've been able to find is actually a TV. It has HDMI, VGA, RCA type analog video inputs. It has a DVD drive tucked in behind the screen, you can plug a USB memory stick or SD card into it to view pictures or play MP3s. And it runs on 12 volts: comes with a wall wart and I think also a cord with a cigarette lighter plug, but it has a standard 2.1 or 2.5 mm coaxial power input jack. I've got a big 4K TV here (replacing my earlier experiments with xdmx etc.) but after possibly a year's use there's definitely degradation of the pixels or underlying active elements. By comparison, both a Philips monitor and my old NEC are rock-solid. It /definitely/ needs config.txt magic, which is a PITA if I have to move RPis around. So that philosophy is workable, but one needs to budget for a replacement. I bought some of those covers for the logitek k-360 keyboards, but the form fitted to the keys stuff could turn inside out and would hold a key down. It was much worse than just being carefull. This was on a medium Logitech should have stuck to selling compilers. Have you considered a touch screen? https://www.raspberrypi.org/products/raspberry-pi-touch-display/ That's smallish at 7 inches but one-piece computer-monitor combos are all the rage on alibaba. A capacitive keyboard doesn't need to be much more than 2 spirals for each "key" etched as printed circuit traces. I want an APL keyboard. One of those controlling CAM kit would be decidedly cool :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: xset +dpms is not controlling monitor powerdown on raspberry pi 3b
On 08/01/17 18:00, Alan Corey wrote: No luck with that here either, it would be very handy to have. But then I'm using an HDMI->VGA adapter and my monitor is ancient. I think the standard was that when horizontal and vertical sync pulses both go away the monitor's supposed to immediately switch off or after a delay period. An adapter shouldn't interfere with that. Never happens though. > On 1/8/17, Gene Heskett wrote: >> Greetings folks; >> >> Running LXDE. Watching the thread with interest. We use pukka Debian here installed on top of Raspbian (in order to get the most up to date loader and RPi kernel). /However/, we select KDE as the window manager AKA desktop, and in general screens stay up etc. as configured. Having said that, one of my colleagues is experiencing problems where all of a sudden the RPi or HDMI-connected monitor stops displaying anything. Disconnecting and reconnecting the HDMI appears to fix that, but nothing relevant is logged explaining the outage; hence we agree that X needs to talk to the GPU better. although we'd note that we see not-dissimilar problems on an Odroid C2, so (and in an effort to keep this OT) there might be generic problems affecting multiple ARM platforms and Debian derivatives. I find that an RPi 2 or 3 drives its HDMI in such a way that a passive adapter suffices to drive an NEC Multisync LCD (specifically, an 1860NX). So even if ones budget doesn't run to an HDMI monitor or TV, there's a fair number of these on eBay. Apart from that we use classic IBM keyboards here, which are fairly resistant to foreign bodies and for which it certainly used to be possible to get squishy covers to keep (in the case of one of our former customers) printing ink out. Of course a lot depends on what colour the swarf is glowing :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Routers with multiple "dirty" interfaces
On 07/12/16 17:00, Mark Morgan Lloyd wrote: Potentially, the bearers come up and go down in an arbitrary sequence, with each event triggering a small number of iptables commands. When the a) Am I correct in believing that Debian's handling of /etc/network/interfaces is single-threaded (non-reentrant)? Definitely NOT a safe assumption. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Routers with multiple "dirty" interfaces
On 07/12/16 16:00, Lennart Sorensen wrote: On Wed, Dec 07, 2016 at 03:41:56PM +, Mark Morgan Lloyd wrote: My apologies for asking something here which is not strictly an ARM question, but I thought I'd run it past the local experts before raising my head in somewhere like LKML. I'm tinkering with some systems (mostly RPis with pukka "Jessie") for routing work, which have multiple "dirty" bearer interfaces with a tunnel to an ISP on top expected to use the route with the numerically-lowest metric. Potentially, the bearers come up and go down in an arbitrary sequence, with each event triggering a small number of iptables commands. When the first interface- whichever it is- comes up various table policies and global rules will be established, and when the last interface goes down the tables will be flushed to their default state. That raises two questions: a) Am I correct in believing that Debian's handling of /etc/network/interfaces is single-threaded (non-reentrant)? b) Is it safe to use /proc/sys/net/ipv4/ip_forward (and the various rp_filter and log_martians states) as counters? So far (b) appears to work, but I'm interested to know whether this is by design or by luck. ip_forward is documented as simply 0 and not 0, so that seems safe rp_filter is documented as having different behaviour for 0, 1 and 2, so that one certainly can not be used as a counter. log_martian is documented as true and false, so that is probably like ip_forward. Really only the kernel bnetwork developers could say for sure. Certainly not in any way an arm related question, it is generic linux in general. Thanks for that, very useful even if it comes with a health warning :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Routers with multiple "dirty" interfaces
My apologies for asking something here which is not strictly an ARM question, but I thought I'd run it past the local experts before raising my head in somewhere like LKML. I'm tinkering with some systems (mostly RPis with pukka "Jessie") for routing work, which have multiple "dirty" bearer interfaces with a tunnel to an ISP on top expected to use the route with the numerically-lowest metric. Potentially, the bearers come up and go down in an arbitrary sequence, with each event triggering a small number of iptables commands. When the first interface- whichever it is- comes up various table policies and global rules will be established, and when the last interface goes down the tables will be flushed to their default state. That raises two questions: a) Am I correct in believing that Debian's handling of /etc/network/interfaces is single-threaded (non-reentrant)? b) Is it safe to use /proc/sys/net/ipv4/ip_forward (and the various rp_filter and log_martians states) as counters? So far (b) appears to work, but I'm interested to know whether this is by design or by luck. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian, Qemu, KVM and Raspberry Pi
On 17/11/16 17:30, Lennart Sorensen wrote: On Thu, Nov 17, 2016 at 08:21:13AM +, Mark Morgan Lloyd wrote: I'm obviously watching these ongoing threads with a lot of interest :-) If I can ask two questions so that there's a summary in a single place ready for me to get back onto this: * Assuming a host kernel that has apparently been built with KVM etc., what's the best way to test that it exposes the required functionality? * What's the recommended Debian guest, and am I correct in assuming that the only indication of whether it's using KVM etc. is its speed of execution? I'm interested in embedding a low-traffic DMZ in a firewall, I think Qemu is adequate for this but wouldn't trust weaker containerisation. KVM on arm requires: CPUs booted in HYP mode (so boot loader has to be done right). That's been in the Raspbian loader for at least a few months. Kernel built with VGIC support (or in the case of the RPi 2 and 3 with emulated VGIC since it doesn't have the normal VGIC that most arm chips have). Think I've done that OK, at least for am RPi2. Either a 64 bit kernel or an lpae kernel. Probably safest ATM to stick to an RPi2, which means LPAE... I'll check. New enough qemu to have support for kvm on arm (not usually a problem anymore). RPi2/3 requires a patched one since the emulated VGIC apparently requires qemu to be tied to specific cores so that the first core can stay responsible for the VGIC emulation and not confuse qemu. I believe that can be forced without a patch. Really the RPi2/3 is just too weird to really support KVM due to the lack of standard expected arm cpu features. I don't expect it to ever have mainline kernel and qemu support due to those hardware deficiensies. OTOH it's cheap and fairly popular. If you have an arm system that boots with the cpu in HYP mode and have a kernel with KVM support enabled. I see the armhf lpae kernel has KVM support enabled in debian. I don't see it in the arm64 kernel config, so it is not enabled there yet. Probably should be. If you have that, then you should be able to run qemu with the -enable-kvm flag and it should work. I'll check, but won't be for a few days due to other pressures. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian, Qemu, KVM and Raspberry Pi
On 16/11/16 20:00, Lennart Sorensen wrote: On Wed, Nov 16, 2016 at 09:09:57AM +0100, Uwe Kleine-König wrote: AFAIK the RPi3 should be supported by the Debian arm64 kernel. So maybe the setup is easier there?! Doesn't solve that it needs VGIC emulation, which I highly doubt has gone into the mainline kernel. So KVM would still not be easy. Even looks like the current emulation patch is mutually exclusive with normal VGIC support in the kernel, so not something ready to go in at this point. I'm obviously watching these ongoing threads with a lot of interest :-) If I can ask two questions so that there's a summary in a single place ready for me to get back onto this: * Assuming a host kernel that has apparently been built with KVM etc., what's the best way to test that it exposes the required functionality? * What's the recommended Debian guest, and am I correct in assuming that the only indication of whether it's using KVM etc. is its speed of execution? I'm interested in embedding a low-traffic DMZ in a firewall, I think Qemu is adequate for this but wouldn't trust weaker containerisation. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian and QEMU virtio-net-device
On 11/11/16 08:00, Ian Campbell wrote: On Wed, 2016-11-09 at 08:18 -0500, Jerry Stuckle wrote: Again, I appreciate any insight you can provide. Looks like you are using the armel vexpress kernel, which AFAICT includes PCI based virtio support, unlike most other ARM configurations which include the MMIO (discovered via DTB or ACPI) variant. (Other platforms like x86 use the PCI based stuff though, so I'd expect it to work) Is there an equivalent to lspci for this type of device? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian and QEMU virtio-net-device
On 08/11/16 21:00, Jerry Stuckle wrote: Thanks for the input. There are no error messages from QEMU, and the console status looks good. I started out with this on the QEMU mailing list, but after lots of looking, people basically threw up their hands. At this point it doesn't *look* like a QEMU problem - but what do I know? I'm just a lowly programmer. If I knew the problem, I'd fix it :) I'm about to hit the sack or something, but just remember that when a programmer has a hard time finding a bug it's almost always because he's looking in the wrong place. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Debian, Qemu, KVM and Raspberry Pi
I prefer to run pukka Debian rather than Raspbian, approximately as described at http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/ http://blog.flexvdi.com/2015/03/17/enabling-kvm-virtualization-on-the-raspberry-pi-2/ and related pages describes getting Qemu+KVM running on an RPi2. Has anybody done this, are there comparable instructions for an RPi3, and- above all- is there a straightforward kernel release suitable for host and guest? I've had it working after a fashion on an RPi2, but I found the process of working out how the standard kernel was built and then merging patches from GOK where to be painful. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian and QEMU virtio-net-device
On 08/11/16 14:30, Ian Campbell wrote: On Tue, 2016-11-08 at 08:51 -0500, Jerry Stuckle wrote: Any other ideas? I'm at a bit of a loss, maybe someone else has some bright ideas. A few bits of info whic might jolt someones memory: I can't usefully help, since while I use Qemu for various targets I tend to use tun etc. networking for historical reasons. I'm sure what I'm doing is thoroughly obsolete, not least because it needs root privilege, but there might possibly be something useful at http://wiki.freepascal.org/Qemu_and_other_emulators Of course the one thing that really does make a big difference is making absolutely sure that Qemu error messages are visible, i.e. at least initially run it from a standard shell. Some of the Qemu console status commands might also turn out to be useful. I suppose this leads on to a question of my own... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian and QEMU virtio-net-device
On 08/11/16 09:30, Ian Campbell wrote: On Tue, 2016-11-08 at 08:42 +, Mark Morgan Lloyd wrote: Does "ifconfig -a" (as root) show the virtio device with some name other than eth0? If so then you might need to edit /etc/udev/rules.d/70-persistent-net.rules to cause it to forget the old device. Is that file still valid on Jessie? I'm not entirely sure to be honest, but I have it on a system installed from Stretch around Easter this year, so maybe? https://lists.debian.org/debian-user/2015/08/msg01083.html seems to suggest that other factors may be at play these days though. Yes, the device naming scheme changes on Stretch, AIUI following other distreaux. Suffixes indicating aliases and VLANs still appear to work as expected. By and large it's an improvement, with interfaces being fixed according to the external connector on the computer (and with this applying to both Ethernet and USB connectors). Note there that I've not explored the situation when an external USB hub is interposed, this could get messy particularly if a hub is replaced with another which has a different number of ports. I suspect that Jessie is somewhere in between, and I don't believe I've seen a 70-persistent-net.rules on any system here irrespective of whether it's got a static population of interfaces or is being used heavily testing hotplugged Ethernet and tethered 'phones. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian and QEMU virtio-net-device
On 08/11/16 08:30, Ian Campbell wrote: On Mon, 2016-11-07 at 22:57 -0500, Jerry Stuckle wrote: The only odd thing I see in the syslog at startup are lines indicating eth0 is not found. Wild stab in the dark: Perhaps things have remembered the mac address of the original (automatically added) device as eth0 and so the virtio device has been renamed out of the way, meaning that /etc/network/interfaces's references to eth0 don't work? Does "ifconfig -a" (as root) show the virtio device with some name other than eth0? If so then you might need to edit /etc/udev/rules.d/70-persistent-net.rules to cause it to forget the old device. Is that file still valid on Jessie? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian on RPi
Mark Morgan Lloyd wrote: Is there still a kernel etc. anywhere for the original Raspberry Pi? I've got a colleague who's dead set on using the one that we've got as a router rather than dipping into our stock of 2's and 3's, and while usb_modeswitch runs fine on pukka Debian I've had very little success with Raspbian. It turns out that problems with usb_modeswitch aren't a Raspbian vs (pukka) Debian issue, or anything to do with kernel version etc. Instead, it appears that usb_modeswitch_dispatcher requires the modemmanager package, and that this isn't in Raspbian Lite or a minimal Debian intended as a router. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian on RPi
Lennart Sorensen wrote: On Wed, Jul 20, 2016 at 02:59:41PM +, Mark Morgan Lloyd wrote: If I had £10 for every bug I'd seen over the last 40 years that nobody wanted to investigate I'd be much more wealthy than I am today. Well looking at the debian bug track system I see no bug report about the problem. I do see a few complaints on the mailing list for it. For example http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=2498 seems to have found a work around for the kernel crash quite recently, so maybe there is a chance a real fix will happen, since it seems to be a kernel bug if you can crash the system. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791677 However, at the moment I believe that the problem doesn't manifest itself on pukka Debian, only on Raspbian. And since this is a Debian list I don't like making too much noise about it until I know what's going on. I suspect that the usb_modeswitch problem is fixed at its v2.4, but that's only in Jessie backports and crashed the RPi2 I tried to run it on. Well that's impolite of it. Sounds like the thing in the above linked post. Rebuilding the backported jessie version for raspbian (if they don't already have that) should be pretty simple too. Yes, that's true. I had to do the same with xl2tpd a few days ago because Debian hadn't picked up a new version from upstream. Didn't take any pleasure in it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian on RPi
Lennart Sorensen wrote: On Tue, Jul 19, 2016 at 10:07:00PM +, Mark Morgan Lloyd wrote: Is there still a kernel etc. anywhere for the original Raspberry Pi? I've got a colleague who's dead set on using the one that we've got as a router rather than dipping into our stock of 2's and 3's, and while usb_modeswitch runs fine on pukka Debian I've had very little success with Raspbian. Well debian armhf won't run on the RPi (only RPi 2 and 3) no matter what you do. Debian armel would run, but be slower for some things (mainly floating point things), although not using thunmb2 would probably make it slower at all things, not that the RPi 1 has support for that. Geneerally I would think Raspbian is the right thing to use and if it has bugs those are worth getting fixed. If I had £10 for every bug I'd seen over the last 40 years that nobody wanted to investigate I'd be much more wealthy than I am today. I suspect that the usb_modeswitch problem is fixed at its v2.4, but that's only in Jessie backports and crashed the RPi2 I tried to run it on. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Debian on RPi
Paul Wise wrote: On Wed, Jul 20, 2016 at 6:07 AM, Mark Morgan Lloyd wrote: Is there still a kernel etc. anywhere for the original Raspberry Pi? The wiki says you need a custom version of the Linux kernel, so probably you'll have to grab the one from Raspbian: https://wiki.debian.org/RaspberryPi I'd been going round in circles with the Debian wiki and Raspbian's download site, but I think I see what you mean: use the kernel etc. from Raspbian plus an armel root. pukka Debian What is pukka Debian? Typo? https://en.wiktionary.org/wiki/pukka i.e. Debian e.g. from http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/ as distinct from Raspbian. In practice I'm already using a Raspbian kernel with a root built on stuff from the link above, and doing something comparable for a v1 (i.e. no hf) doesn't sound like too big a deal. The issue that's causing this is that usb_modeswitch will work properly with a 4G router on Debian on a Pi3, but not on Raspbian on a Pi2 or Pi1. I feel on firmer ground trying to faultfind this on with pukka Debian, looking for different binary or script files hasn't got me anywhere. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Debian on RPi
Is there still a kernel etc. anywhere for the original Raspberry Pi? I've got a colleague who's dead set on using the one that we've got as a router rather than dipping into our stock of 2's and 3's, and while usb_modeswitch runs fine on pukka Debian I've had very little success with Raspbian. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Rebuilding xl2tpd
Mark Morgan Lloyd wrote: I've been trying to rebuild xl2tpd 1.3.6 (rationale etc. below) on a Raspberry Pi before moving to the next version since its changelog suggests that it fixes a problem we're experiencing. Whether I use pukka Debian Jessie as described at http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/ or the current Raspbian Lite, the stripped binaries come out about 1K smaller than expected and crash the system as soon as there's network traffic. I'm a comparative beginner at building stuff on Debian, although I've been doing it for rather a long time on lesser distreaux. Are there any obvious gotchas that I need to be aware of, or anything Pi-specific that might need to be added to the makefile? Background info: Our ISP (Andrews & Arnold in the UK) provides a service where customers may connect using PPP-over-L2TP via e.g. 4G, which allows mailservers etc. to remain routable even if a copper/fibre line goes down. Using xl2tpd 1.3.6 I'm finding that the daemon freezes when the connection is broken, the changelog for 1.3.7 suggests that this is a fixed problem. There's also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760602 which might be relevant. The cause of the crash appears to be that the xl2tpd binary must not assume kernel support. I've managed to build a 1.3.7 which I'm currently testing, but don't pretend to understand what I'm doing. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Rebuilding xl2tpd
Paul Wise wrote: On Thu, Jun 9, 2016 at 5:14 AM, Mark Morgan Lloyd wrote: Red herring alert :-) The Debian is only good for an RPi2 or later FYI, given suitable boot blobs and Linux kernel, Debian armel userland can run on the RPi1. Noted, but I was referring to the particular one I'm running (link earlier). The bottom line is that I can't rebuild xl2tpd on Raspbian either. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Rebuilding xl2tpd
Lennart Sorensen wrote: On Wed, Jun 08, 2016 at 07:45:07PM +, Mark Morgan Lloyd wrote: I've been trying to rebuild xl2tpd 1.3.6 (rationale etc. below) on a Raspberry Pi before moving to the next version since its changelog suggests that it fixes a problem we're experiencing. Whether I use pukka Debian Jessie as described at http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/ or the current Raspbian Lite, the stripped binaries come out about 1K smaller than expected and crash the system as soon as there's network traffic. .. Did you get that backwards? For a raspberry pi, you need the v6 code. Normal Debian armhf uses v7 with thumb-2 and would only work on a raspberry pi 2 or better, not the original. Red herring alert :-) The Debian is only good for an RPi2 or later, if I look at something on it that I know runs and that I've not changed: /bin$ ls -l bash -rwxr-xr-x 1 root root 679084 Nov 12 2014 bash /bin$ readelf -a bash |grep Tag_ Tag_CPU_name: "7-A" Tag_CPU_arch: v7 .. Or on recent Raspbian Lite: /bin$ ls -l bash -rwxr-xr-x 1 root root 863400 Oct 18 2014 bash /bin$ readelf -a bash |grep Tag_ Tag_CPU_name: "6" Tag_CPU_arch: v6 .. The Debian with xl2tpd on it is actually an RPi3. I've tried compiling on several systems but my latest attempt was on a fresh Raspbian Lite on an RPi2 in case there was something odd about the compiler/libraries on other systems. However in all cases I see about the same thing: make completes without error but the newly compiled binaries are a bit smaller than expected, and the system crashes as soon as the daemon starts handling traffic. I'm still at the stage of assuming that I'm making some silly mistake due to inexperience on this combination of distro and platform. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Rebuilding xl2tpd
I've been trying to rebuild xl2tpd 1.3.6 (rationale etc. below) on a Raspberry Pi before moving to the next version since its changelog suggests that it fixes a problem we're experiencing. Whether I use pukka Debian Jessie as described at http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/ or the current Raspbian Lite, the stripped binaries come out about 1K smaller than expected and crash the system as soon as there's network traffic. Looking at the original and newly-built binaries using readelf, I can see that the original has reference to 0x0001 (NEEDED)Shared library: [ld-linux-armhf.so.3] which the new one lacks. I also see that the original has Displaying notes [...] Attribute Section: aeabi File Attributes Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Tag_CPU_arch_profile: Application Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv3-D16 while the new one has Displaying notes [...] Attribute Section: aeabi File Attributes Tag_CPU_name: "6" Tag_CPU_arch: v6 Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_FP_arch: VFPv2 Does this indicate that the makefile etc. has failed to work out the target architecture correctly? I'm a comparative beginner at building stuff on Debian, although I've been doing it for rather a long time on lesser distreaux. Are there any obvious gotchas that I need to be aware of, or anything Pi-specific that might need to be added to the makefile? Background info: Our ISP (Andrews & Arnold in the UK) provides a service where customers may connect using PPP-over-L2TP via e.g. 4G, which allows mailservers etc. to remain routable even if a copper/fibre line goes down. Using xl2tpd 1.3.6 I'm finding that the daemon freezes when the connection is broken, the changelog for 1.3.7 suggests that this is a fixed problem. There's also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760602 which might be relevant. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
