Re: NetBSD7 RC1 rpi image : Incorrect super block
On Wed, Jul 01, 2015 at 08:43:05AM +0200, Martin Husemann wrote: On Tue, Jun 30, 2015 at 09:20:04PM +0530, Mayuresh wrote: # dd if=rpi_inst.img of=/dev/rld0 bs=4k rld0 sounds wrong, maybe you now have a copy of the image as a rgular file in /dev/rld0 ? I picked rld0, because ld0 was in dmesg. I have attached dmesg in last post. Seems it refers to a card reader device. As such disklabel also shows the partition on /dev/ld0 after dd was run. (Attached disklabel output in last mail. Mayuresh.
Re: NetBSD7 RC1 rpi image : Incorrect super block
On Wed, Jul 01, 2015 at 01:55:12PM +0530, Mayuresh wrote: I picked rld0, because ld0 was in dmesg. I have attached dmesg in last post. You probably want /dev/rld0d then (assuming you are on x86). Please run: ls -l /dev/rld0* and compare the size for rld0 to, say, rld0a. Martin
Re: NetBSD 7.0_RC1
On Wed, Jul 01, 2015 at 08:36:29AM -0400, Christos Zoulas wrote: On Jul 1, 2:01pm, 76nem...@gmx.ch (76nem...@gmx.ch) wrote: -- Subject: Re: NetBSD 7.0_RC1 | Hi All, | Since it's not absolutely mandatory to have PIE on every executable, | it should be possible to force PIE only on some part of tree by inserting | in the makefile someting like that: |.if !empty(.CURDIR:M/usr/src/somepath) | MKPIE=YES | | Is this idea reasonable? Why? I'd rather fix the code so that it works. christos Effectively fixing the code is a better solution. Unfortunately, I haven't yet the time and knowledge to fix it. I should rely on somebody else to correct the bugs. This is the reason why I have suggested a lazy workaround. I hope to find soon the time to read the code in order to be able to modify it. regards, Alan
Re: NetBSD 7.0_RC1
On Tue, Jun 30, 2015 at 08:45:06PM +0100, Alexander Nasonov wrote: Christos Zoulas wrote: I think that this problem has been fixed on HEAD, we'll issue a pullup... Yep, it has been fixed in HEAD. But ran into other compilation issues ... Alex Hi All, Since it's not absolutely mandatory to have PIE on every executable, it should be possible to force PIE only on some part of tree by inserting in the makefile someting like that: .if !empty(.CURDIR:M/usr/src/somepath) MKPIE=YES Is this idea reasonable? By the way, when I have set as a compiler flag -march=native, the compilation failed too with an error indicating that native was an unkown arch. If this is interesting, I can redo the compilation to have the exact error message. Kind regards, Alan
Re: NetBSD7 RC1 rpi image : Incorrect super block
Mayuresh mayur...@acm.org writes: #ls -l /dev/rld0* -rw-r--r-- 1 root wheel 62914560 Jun 30 21:04 /dev/rld0 crw-r- 1 root operator 69, 0 Jun 30 20:50 /dev/rld0a rld0 is a regular file. Which means (probably) that it didn't exist, and you just put the bits in it. You proabably want rld0d (i386/amd64) or rld0c, to be the whole disk without using disklabels. pgpBoA262Lmqy.pgp Description: PGP signature
Re: NetBSD7 RC1 rpi image : Incorrect super block
On Wed, Jul 01, 2015 at 10:29:03AM +0200, Martin Husemann wrote: You probably want /dev/rld0d then (assuming you are on x86). Please run: ls -l /dev/rld0* and compare the size for rld0 to, say, rld0a. Here is the output. How do I figure out the right device from this? #ls -l /dev/rld0* -rw-r--r-- 1 root wheel 62914560 Jun 30 21:04 /dev/rld0 crw-r- 1 root operator 69, 0 Jun 30 20:50 /dev/rld0a crw-r- 1 root operator 69, 1 Jul 5 2013 /dev/rld0b crw-r- 1 root operator 69, 2 Jul 5 2013 /dev/rld0c crw-r- 1 root operator 69, 3 Jul 5 2013 /dev/rld0d crw-r- 1 root operator 69, 4 Jul 5 2013 /dev/rld0e crw-r- 1 root operator 69, 5 Jul 5 2013 /dev/rld0f crw-r- 1 root operator 69, 6 Jul 5 2013 /dev/rld0g crw-r- 1 root operator 69, 7 Jul 5 2013 /dev/rld0h crw-r- 1 root operator 69, 524288 Jul 5 2013 /dev/rld0i crw-r- 1 root operator 69, 524289 Jul 5 2013 /dev/rld0j crw-r- 1 root operator 69, 524290 Jul 5 2013 /dev/rld0k crw-r- 1 root operator 69, 524291 Jul 5 2013 /dev/rld0l crw-r- 1 root operator 69, 524292 Jul 5 2013 /dev/rld0m crw-r- 1 root operator 69, 524293 Jul 5 2013 /dev/rld0n crw-r- 1 root operator 69, 524294 Jul 5 2013 /dev/rld0o crw-r- 1 root operator 69, 524295 Jul 5 2013 /dev/rld0p Will try rld0d, it is i386. Mayuresh.
Re: NetBSD7 RC1 rpi image : Incorrect super block
On Wed, Jul 01, 2015 at 06:41:51AM -0400, Greg Troxel wrote: rld0 is a regular file. Which means (probably) that it didn't exist, and you just put the bits in it. You proabably want rld0d (i386/amd64) or rld0c, to be the whole disk without using disklabels. Got the rld0 mistake. However I got input/output error when using rld0d (and other letters also). Finally I ran dd command from a Linux machine and now I got a correct card. I am able to boot NetBSD on pi now. Mayuresh.
Re: NetBSD 7.0_RC1
On Jul 1, 2:01pm, 76nem...@gmx.ch (76nem...@gmx.ch) wrote: -- Subject: Re: NetBSD 7.0_RC1 | Hi All, | Since it's not absolutely mandatory to have PIE on every executable, | it should be possible to force PIE only on some part of tree by inserting | in the makefile someting like that: |.if !empty(.CURDIR:M/usr/src/somepath) | MKPIE=YES | | Is this idea reasonable? Why? I'd rather fix the code so that it works. christos
Re: leap second success
On 06/30/15 19:30, Greg Troxel wrote: All my NetBSD systems correctly handled the leap second, and are now showing leap indicator 01. analog xclock nicely held the second hand at 59 for 2s and ticked to 0 in time with the beep on WWV (US national time standard broadcast on HF). macs, on the other hand, do not seem to be doing so well. Most of the world seems to have done well; I see only one pool peer that's off 1s now. I have a RPiB+ running as my network time keeped, ntpd server for my LAN, it said it inserted 1 second @ midnight, see below from my syslog file. *Byah* :-) Jun 23 17:06:15 rpi syslogd[11087]: restart Jun 24 08:06:15 rpi syslogd[11087]: restart Jun 24 17:06:15 rpi syslogd[11087]: restart Jun 25 17:06:15 rpi syslogd[11087]: restart Jun 26 17:06:15 rpi syslogd[11087]: restart Jun 27 17:06:16 rpi syslogd[11087]: restart Jun 28 10:06:15 rpi syslogd[11087]: restart Jun 28 17:06:15 rpi syslogd[11087]: restart Jun 29 17:06:15 rpi syslogd[11087]: restart Jun 30 17:06:15 rpi syslogd[11087]: restart Jul 1 00:00:00 rpi ntpd[1400]: Inserting positive leap second. NetBSD rpi 7.0_BETA NetBSD 7.0_BETA (RPI.201503272230Z) evbarm -- William A. Mahaffey III -- The M1 Garand is without doubt the finest implement of war ever devised by man. -- Gen. George S. Patton Jr.
Re: NetBSD 7.0_RC1
On Jul 1, 6:58pm, 76nem...@gmx.ch (76nem...@gmx.ch) wrote: -- Subject: Re: NetBSD 7.0_RC1 | Effectively fixing the code is a better solution. | | Unfortunately, I haven't yet the time and knowledge | to fix it. I should rely on somebody else to correct the bugs. | This is the reason why I have suggested a lazy workaround. | | I hope to find soon the time to read the code in order | to be able to modify it. Post the errors please. I just built a full amd64 tree with MKPIE (and discovered that gdb does not work with PIE binaries :-( in the process..) christos
Re: NetBSD7 RC1 rpi image : Incorrect super block
On Tue, Jun 30, 2015 at 09:20:04PM +0530, Mayuresh wrote: # dd if=rpi_inst.img of=/dev/rld0 bs=4k rld0 sounds wrong, maybe you now have a copy of the image as a rgular file in /dev/rld0 ? Martin
Re: leap second success
On Jun 30, 2015 5:25 PM, Greg Troxel g...@ir.bbn.com wrote: All my NetBSD systems correctly handled the leap second, and are now showing leap indicator 01. analog xclock nicely held the second hand at 59 for 2s and ticked to 0 in time with the beep on WWV (US national time standard broadcast on HF). macs, on the other hand, do not seem to be doing so well. Most of the world seems to have done well; I see only one pool peer that's off 1s now. Darn, I was watching my Mac. Should have watched NetBSD! Andy
Re: Prepping to install: a digression
Date:Wed, 01 Jul 2015 10:40:24 -0453 From:William A. Mahaffey III w...@hiwaay.net Message-ID: 55940871.60...@hiwaay.net | However, this time | I can boot back into the boot media when I plug it in reboot, I think | because I *didn't* do the 'raidctl -A root raid0' command during my | shell excursion. That would be why - and you really do NOT want to do that until you are certain that everything is correctly set up and working. Boot back to the state you showed at the end of LIST.setup2.txt (the output from setup0 and setup1 was not useful - that's just stuff working normally, we do not need to see that). That is, boot with root on sd0a and the (later intended) root on /altroot with /altroot/usr also mounted (/altroot/home should make no difference one way or the other). Next chroot /altroot At that point run a bunch of commands and make sure everything is working (and check that /sbin/init exists and is executable - yoy won't be able to run that one). Check that /dev is sane (entries for the raids you need, the wd devices you have, console, null, ptys, ... (or completely empty). Run fdisk on wd0 (or whichever drive you intend to actually boot from), (While you are still chrooted to /altroot). Make sure it is correctly set up, it should have an MBR, or PMBR, and should be marked as bootable, with a bootable partition on it, and boot code correctly installed. Make sure you can understand how that code is going to locate /boot (if you want it to use the one that is in /altroot, then the offsets of the partitions all need to be just right - you will need to get someone who has set up actually booting from a raid1 to verify your setup, I don't run my systems that way, I prefer a separate boot partition on wd0 (duplicated on wd1 or wd2 or whatever is appropriate). Also check that the bios is set to actually boot from the drive you think, which can be tricky if you have a whole bunch of basically identical drives. What the bios thinks of as the boot drive might not be the one you are expecting. For problems at that stage, what is important to see is not the raid setup, but the drive layouts, labels (fdisk, gpt, disklabel - whatever is actually in use) of the boot drive, and the boot raid partition. Once you have all that right, as best you believe it can be, boot without sd0 (the thumb drive, I assume) connected - in that state, if you get to the state where the system looks to be booting, but cannot find a root filesystem (that is, if the kernel boots, lists the hardware, etc, and then fails to find root) then you're in a good situation. If it is still unable to boot, you don't have the boot setup correct yet, and you will need to work on that part - making stde the MBR or PMBR is correct, installboot has been done correctly, and should be able to locate /boot at one of the (very few) places it looks. Once booting is right to the state of not finding root, and if you have done the chroot part above, and are fairly sure that the system is correctly installed and all the important parts are there, then you should reboot from sd0, and do the raidctl -A root raid0 bit so that raidframe will make raid0a the root filesystem - then reboot again without sd0 and all should be OK. Finally, if you need to (almost) start all of this again (which you easily might) - skip everything related to /home. You don't need all that space just to get booted, and initing that 3.5TB raid takes a long time. Everything else should be fairly fast - so it is less painful to do it again, and again, until it all works. Once the system is properly up and running, you can easily configure that raid array using the running system, mount it on /mnt. copy whatever you might have added to /home in the interim to it, fix fstab to mount it on /home, and then reboot.But only after you can boot, and shutdown and reboot, successfully, and with no hassles, without it. kre
