Re: ISO image: where is the CLANG compiler?

[Jeffrey Bouquet]

On Sat, 21 Jan 2017 16:47:56 -0600, Benjamin Kaduk  wrote:

> On Thu, Jan 19, 2017 at 07:38:30PM +, Glen Barber wrote:
> > 
> > Random thought:
> > 
> > Brought up out-of-band, can you try this from a memstick.img and your
> > already-built userland/kernel to do what you had originally tried to
> > install the system?
> > 
> >  # make -C /usr/src WITHOUT_SYSTEM_COMPILER=1 DESTDIR=/wherever installworld
> > 
> > I think this is why cc(1)/clang(1) is not being used from /usr/obj, and
> > you don't have a compiler to compile the compiler.
> 
> Sorry for jumping in late, and thanks for bringing this up -- I was surprised
> that we had gone so long without someone making the claim that a compiler
> should not be necessary for installworld/installkernel (as was my 
> understanding).
> If indeed a compiler is necessary for those (perhaps only under certain
> circumstances such as those experienced by Oliver) it would be good to 
> understand
> why.
> 
> -Ben
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


That may be a reason to develop the not-specific (sorry...) idea that 
installworld
should install to a small duplicate of  where it Does, and  complete, before 
the Actual
installworld so that if the latter cannot complete, a small rescue shell with 
rsync
embedded or an equivalent can copy the bare-minimum set of files over the 
mixture of new and old... which I have had to several times do more or less
piecemeal, and more often than not sufficed to bring the system back whole. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ISO image: where is the CLANG compiler?

[O. Hartmann]

Am Thu, 19 Jan 2017 19:38:30 +
Glen Barber  schrieb:

> On Thu, Jan 19, 2017 at 07:10:00PM +, Glen Barber wrote:
> > On Thu, Jan 19, 2017 at 10:16:46AM +0100, O. Hartmann wrote:  
> > > On Thu, 19 Jan 2017 06:58:16 +0100
> > > Matthias Apitz  wrote:
> > >   
> > > > El día Wednesday, January 18, 2017 a las 08:00:04PM -0500, Allan Jude
> > > > escribió:
> > > >   
> > > > > On 2017-01-18 14:37, O. Hartmann wrote:
> > > > > > Am Wed, 18 Jan 2017 16:38:32 +0100
> > > > > > Matthias Apitz  schrieb:
> > > > > > 
> > > > > >> Why you do not just boot from USB some mem stick image, mount some 
> > > > > >> disk
> > > > > >> space to /mnt, svn checkout CURRENT to /mnt and build a booteable 
> > > > > >> system
> > > > > >> (world and kernel) and install to DESTDIR=/mnt ?
> > > > > >>
> > > > > >> I do not understand all this hassle?
> > > > > >>
> > > > > >>matthias
> > > > > >>
> > > > > > 
> > > > > > Wow!
> > > > > > 
> > > > > > As I initially stated, that is EXACTLY what I was inclined to do 
> > > > > > except
> > > > > > the fact that I had already an intact /usr/obj and usr/src with a
> > > > > > complete compiled system.
> > > > > > 
> > > > > > I booted from mem stick and I was lost due to no cc!
> > > > > > 
> > > > > > Even for "make installworld" it seems I have to rely on the 
> > > > > > compiler. And
> > > > > > the images (ISO, memstick et cetera) provided these days do not 
> > > > > > contain
> > > > > > any clang.
> > > > 
> > > > Yes, you will need it and it will complain about missing it, if for
> > > > example you moved 'obj and 'src' to other dirs after 'make build...'
> > > > 
> > > > But, in your case the mem image really is lacking the cc/clang; I
> > > > fetched the image an did:
> > > > 
> > > > 
> > > > # mdconfig -a -t vnode -u 1 -f
> > > > ~guru/Downloads/FreeBSD-11.0-RELEASE-amd64-memstick.img # mount -o
> > > > ro /dev/md1p3 /mnt # find /mnt -name clang
> > > > /mnt/usr/share/doc/llvm/clang
> > > > /mnt/usr/lib/clang
> > > > /mnt/usr/lib/debug/usr/lib/clang
> > > > # find /mnt -name cc
> > > > /mnt/usr/include/netinet/cc
> > > > 
> > > > With this img  alone, you can't compile a system :-(
> > > > 
> > > > Setup a system from DVD and build your own image containing a complete
> > > > system on an USB key; with this boot your damaged system, recompile and
> > > > reinstall world and kernel. If you (O. Hartmann) need a step by step
> > > > guide, I could send it to you.
> > > > 
> > > > matthias
> > > >   
> > > 
> > > Hello,
> > > 
> > > thanks for your help offering! very kind.
> > > 
> > > I've already solved the problem - not with the suggested process, but via
> > > copying missing libs and files from and identical intact source. After 
> > > that, I
> > > ran make buildword/buildkernel and was able to successfully install the 
> > > new
> > > system.
> > > 
> > > As I stated before: I already had a complete compiled world and kernel 
> > > existing
> > > in their proper, intact folders (usr/src and usr/obj). There was no need 
> > > to
> > > compile a whole world.
> > > Intending to "make installworld" failed, this is the real problem, 
> > > because the
> > > ISO/memstick images provided lack obviously in the required 
> > > infrastructure and
> > > so these images are worthless for sophisticated rescue operations - or 
> > > even
> > > such a simple ask as described initially in my posting.
> > > 
> > > I created images on CURRENT of my own - they all lack in the ability of 
> > > having
> > > the necessary tools aboard. So I consider every image useless for rescue
> > > operations except, maybe, the DVD image - but this one is not provided 
> > > anymore.
> > > For what reason? Time? Accepted. Space/disk usage? Well, welcome back in 
> > > the
> > > stoneage of computer technology ... 
> > > 
> > > I remember faintly that there was a small discussion on the @CURRENT 
> > > list, but
> > > I didn't realize that the result would be the extraction of the compiler.
> > > 
> > > Just for the record: most servers delivered to us do not have CD/DVD 
> > > drives
> > > anymore - they are outdated and considered an extra these days. 
> > > Purchasing 1 GB
> > > USB thumbdrives is getting even harder, smallest size my employer 
> > > provides now
> > > is 2 GB. And most optical drives are DVD. From my point of view - and 
> > > this is a
> > > personal view - the "standard" is > 1GB so there is no need to break down 
> > > by
> > > force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 
> > > GB. I'd
> > > consider having < 2GB the line of standards (2 GB USB mem drive).
> > > And for those, with need of very small images, smaller images could be 
> > > provided
> > > as the extra.
> > >   
> > 
> > I do want to weigh in here and inform I am actively watching this
> > thread.  clang(1) is not in disc1.iso or bootonly.iso because the
> > MK_TOOLCHAIN knob is disabled in the 

Re: r312602: panic: Panic String: __lockmgr_args: unknown lockmgr request 0x0

[O. Hartmann]

Am Sat, 21 Jan 2017 21:51:40 +0100
"O. Hartmann"  schrieb:

> Am Sat, 21 Jan 2017 21:13:49 +0100
> Mateusz Guzik  schrieb:
> 
> > On Sat, Jan 21, 2017 at 08:45:55PM +0100, O. Hartmann wrote:  
> > > The most recent CURRENT panics spontanously and crashes with the error 
> > > message:
> > > 
> > >  
> > > Panic String: __lockmgr_args: unknown lockmgr request 0x0
> > > 
> > 
> > That's a braino in r312600, will be fixed shortly.
> >   
> 
> ??? What is a "braino"?
> 

Great ... now I have two dead systems ... this fu... corrupts a whole SSD ... 
the UFS
filesystem is corrupted, most of /sbin /boot /bin /usr/sbin and /usr/bin has 
NULL
fileszies :-(

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpNDsZ48RtHX.pgp
Description: OpenPGP digital signature

Re: r312602: panic: Panic String: __lockmgr_args: unknown lockmgr request 0x0

[O. Hartmann]

Am Sat, 21 Jan 2017 21:13:49 +0100
Mateusz Guzik  schrieb:

> On Sat, Jan 21, 2017 at 08:45:55PM +0100, O. Hartmann wrote:
> > The most recent CURRENT panics spontanously and crashes with the error 
> > message:
> > 
> >  
> > Panic String: __lockmgr_args: unknown lockmgr request 0x0
> >   
> 
> That's a braino in r312600, will be fixed shortly.
> 

??? What is a "braino"?

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpvaQcKwCB5R.pgp
Description: OpenPGP digital signature

Re: Fix /etc/rc.d/random umask handling (/entropy permissions)

[Lu Tung-Pin]

On 2017-01-21 22:01, Jilles Tjoelker wrote:

[Adding Cc: Dag-Erling Smørgrav who committed r273957 which seems to
have introduced this]
On Sat, Jan 21, 2017 at 01:21:42AM +, Lu Tung-Pin wrote:

A 2014 change broke the umask handling in /etc/rc.d/random,
leaving /entropy with ug+r permissions. Quick fix attached,



Edit: go+r permissions.

Switching the umask here will avoid incorrect permissions on /entropy 
on

new installations, but will not fix existing systems. A chmod command
may be useful here.


Note that random_start() first removes /entropy via feed_dev_random().
There's also a removal in random_stop(). Provided that a removal occurs,
the chmod won't be necessary on machines with an existing go+r /entropy.

I'm wondering, though: Would it be better to replace all the umask
fiddling with simple chmods? Every other rc.d script uses chmod if it
needs to set tighter permissions. When umask is used (dmesg, mountd,
syslogd), it's with a relaxed 022 setting.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ISO image: where is the CLANG compiler?

[O. Hartmann]

Am Sat, 21 Jan 2017 22:20:01 +0100
"O. Hartmann"  schrieb:

> Am Thu, 19 Jan 2017 19:38:30 +
> Glen Barber  schrieb:
> 
> > On Thu, Jan 19, 2017 at 07:10:00PM +, Glen Barber wrote:  
> > > On Thu, Jan 19, 2017 at 10:16:46AM +0100, O. Hartmann wrote:
> > > > On Thu, 19 Jan 2017 06:58:16 +0100
> > > > Matthias Apitz  wrote:
> > > > 
> > > > > El día Wednesday, January 18, 2017 a las 08:00:04PM -0500, Allan Jude
> > > > > escribió:
> > > > > 
> > > > > > On 2017-01-18 14:37, O. Hartmann wrote:  
> > > > > > > Am Wed, 18 Jan 2017 16:38:32 +0100
> > > > > > > Matthias Apitz  schrieb:
> > > > > > >   
> > > > > > >> Why you do not just boot from USB some mem stick image, mount 
> > > > > > >> some disk
> > > > > > >> space to /mnt, svn checkout CURRENT to /mnt and build a 
> > > > > > >> booteable system
> > > > > > >> (world and kernel) and install to DESTDIR=/mnt ?
> > > > > > >>
> > > > > > >> I do not understand all this hassle?
> > > > > > >>
> > > > > > >>  matthias
> > > > > > >>  
> > > > > > > 
> > > > > > > Wow!
> > > > > > > 
> > > > > > > As I initially stated, that is EXACTLY what I was inclined to do 
> > > > > > > except
> > > > > > > the fact that I had already an intact /usr/obj and usr/src with a
> > > > > > > complete compiled system.
> > > > > > > 
> > > > > > > I booted from mem stick and I was lost due to no cc!
> > > > > > > 
> > > > > > > Even for "make installworld" it seems I have to rely on the 
> > > > > > > compiler. And
> > > > > > > the images (ISO, memstick et cetera) provided these days do not 
> > > > > > > contain
> > > > > > > any clang.  
> > > > > 
> > > > > Yes, you will need it and it will complain about missing it, if for
> > > > > example you moved 'obj and 'src' to other dirs after 'make build...'
> > > > > 
> > > > > But, in your case the mem image really is lacking the cc/clang; I
> > > > > fetched the image an did:
> > > > > 
> > > > > 
> > > > > # mdconfig -a -t vnode -u 1 -f
> > > > > ~guru/Downloads/FreeBSD-11.0-RELEASE-amd64-memstick.img # mount -o
> > > > > ro /dev/md1p3 /mnt # find /mnt -name clang
> > > > > /mnt/usr/share/doc/llvm/clang
> > > > > /mnt/usr/lib/clang
> > > > > /mnt/usr/lib/debug/usr/lib/clang
> > > > > # find /mnt -name cc
> > > > > /mnt/usr/include/netinet/cc
> > > > > 
> > > > > With this img  alone, you can't compile a system :-(
> > > > > 
> > > > > Setup a system from DVD and build your own image containing a complete
> > > > > system on an USB key; with this boot your damaged system, recompile 
> > > > > and
> > > > > reinstall world and kernel. If you (O. Hartmann) need a step by step
> > > > > guide, I could send it to you.
> > > > > 
> > > > >   matthias
> > > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > thanks for your help offering! very kind.
> > > > 
> > > > I've already solved the problem - not with the suggested process, but 
> > > > via
> > > > copying missing libs and files from and identical intact source. After 
> > > > that, I
> > > > ran make buildword/buildkernel and was able to successfully install the 
> > > > new
> > > > system.
> > > > 
> > > > As I stated before: I already had a complete compiled world and kernel 
> > > > existing
> > > > in their proper, intact folders (usr/src and usr/obj). There was no 
> > > > need to
> > > > compile a whole world.
> > > > Intending to "make installworld" failed, this is the real problem, 
> > > > because the
> > > > ISO/memstick images provided lack obviously in the required 
> > > > infrastructure and
> > > > so these images are worthless for sophisticated rescue operations - or 
> > > > even
> > > > such a simple ask as described initially in my posting.
> > > > 
> > > > I created images on CURRENT of my own - they all lack in the ability of 
> > > > having
> > > > the necessary tools aboard. So I consider every image useless for rescue
> > > > operations except, maybe, the DVD image - but this one is not provided 
> > > > anymore.
> > > > For what reason? Time? Accepted. Space/disk usage? Well, welcome back 
> > > > in the
> > > > stoneage of computer technology ... 
> > > > 
> > > > I remember faintly that there was a small discussion on the @CURRENT 
> > > > list, but
> > > > I didn't realize that the result would be the extraction of the 
> > > > compiler.
> > > > 
> > > > Just for the record: most servers delivered to us do not have CD/DVD 
> > > > drives
> > > > anymore - they are outdated and considered an extra these days. 
> > > > Purchasing 1 GB
> > > > USB thumbdrives is getting even harder, smallest size my employer 
> > > > provides now
> > > > is 2 GB. And most optical drives are DVD. From my point of view - and 
> > > > this is a
> > > > personal view - the "standard" is > 1GB so there is no need to break 
> > > > down by
> > > > force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 
> > > > GB. I'd
> > > > consider having 

RE: vt(4) chops off the leftmost three columns

[Anindya Mukherjee]

Thanks! I needed a breakdown like this. I'll need to study the code a bit more.

Anindya

From: Adrian Chadd [adrian.ch...@gmail.com]
Sent: January 20, 2017 3:11 PM
To: Anindya Mukherjee
Cc: freebsd-current@freebsd.org
Subject: Re: vt(4) chops off the leftmost three columns

hiya,

Mechanically it doesn't look /that/ hard:

* vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
Ideally we'd have them as two separate modules, so you could load
"vesa" without needing the syscons bits.
* Maybe then write a vt 'fb' interface to talk to the old-school
framebuffer interface
* Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
creator, etc!) through the fb interface, rather than reimplementing
its own.

I looked at it and it doesn't look /that/ hard. If you only cared
about vesa, then you could do something like what 'creator' and
'creator_vt' did in sys/dev/fb/ . It's just sad that the vt interface
to the screen buffer isn't as complete as the older school framebuffer
interface is.


-adrian


On 19 January 2017 at 12:35, Anindya Mukherjee  wrote:
> Hi Adrian,
>
> I was looking at the source for the vt driver. Wondering how much work it is 
> to add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
> 640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
>
> Also, how dependent is splash/screensaver support on the VESA implementation?
>
> Thanks,
> Anindya
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ISO image: where is the CLANG compiler?

[Benjamin Kaduk]

On Thu, Jan 19, 2017 at 07:38:30PM +, Glen Barber wrote:
> 
> Random thought:
> 
> Brought up out-of-band, can you try this from a memstick.img and your
> already-built userland/kernel to do what you had originally tried to
> install the system?
> 
>  # make -C /usr/src WITHOUT_SYSTEM_COMPILER=1 DESTDIR=/wherever installworld
> 
> I think this is why cc(1)/clang(1) is not being used from /usr/obj, and
> you don't have a compiler to compile the compiler.

Sorry for jumping in late, and thanks for bringing this up -- I was surprised
that we had gone so long without someone making the claim that a compiler
should not be necessary for installworld/installkernel (as was my 
understanding).
If indeed a compiler is necessary for those (perhaps only under certain
circumstances such as those experienced by Oliver) it would be good to 
understand
why.

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Fix /etc/rc.d/random umask handling (/entropy permissions)

[Jilles Tjoelker]

[Adding Cc: Dag-Erling Smørgrav who committed r273957 which seems to
have introduced this]
On Sat, Jan 21, 2017 at 01:21:42AM +, Lu Tung-Pin wrote:
> A 2014 change broke the umask handling in /etc/rc.d/random,
> leaving /entropy with ug+r permissions. Quick fix attached,
> mirroring random_stop() behavior.

> (Incidentally, /usr/libexec/save-entropy is still fine for
> /var/db/entropy/*, as is /etc/rc.d/random for the new
> /boot/entropy.)

> --- /etc/rc.d/random.old  2017-01-21 11:48:30.975009000 +1100
> +++ /etc/rc.d/random  2017-01-19 18:04:34.224632000 +1100
> @@ -20,12 +20,15 @@
>  
>  save_dev_random()
>  {
> + oumask=`umask`
> + umask 077
>   for f ; do
>   if :>>"$f" ; then
>   debug "saving entropy to $f"
>   dd if=/dev/random of="$f" bs=4096 count=1 2>/dev/null
>   fi
>   done
> + umask ${oumask}
>  }
>  
>  feed_dev_random()

Switching the umask here will avoid incorrect permissions on /entropy on
new installations, but will not fix existing systems. A chmod command
may be useful here.

On another note,  if :>>"$f"  is bogus. Since : is a special builtin, a
redirection error causes the shell to abort the script. The conditional
seems to have been added to show error messages when the entropy file
cannot be written without showing dd's statistics. I think this can be
done more easily using dd's status=none parameter.

My revised patch is below:

Index: etc/rc.d/random
===
--- etc/rc.d/random (revision 311446)
+++ etc/rc.d/random (working copy)
@@ -20,12 +20,14 @@
 
 save_dev_random()
 {
+   oumask=`umask`
+   umask 077
for f ; do
-   if :>>"$f" ; then
-   debug "saving entropy to $f"
-   dd if=/dev/random of="$f" bs=4096 count=1 2>/dev/null
-   fi
+   debug "saving entropy to $f"
+   dd if=/dev/random of="$f" bs=4096 count=1 status=none &&
+   chmod 600 "$f"
done
+   umask ${oumask}
 }
 
 feed_dev_random()

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r312602: panic: Panic String: __lockmgr_args: unknown lockmgr request 0x0

[Mateusz Guzik]

On Sat, Jan 21, 2017 at 08:45:55PM +0100, O. Hartmann wrote:
> The most recent CURRENT panics spontanously and crashes with the error 
> message:
> 
>  
> Panic String: __lockmgr_args: unknown lockmgr request 0x0
> 

That's a braino in r312600, will be fixed shortly.

-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r312602: panic: Panic String: __lockmgr_args: unknown lockmgr request 0x0

[O. Hartmann]

The most recent CURRENT panics spontanously and crashes with the error message:

 
Panic String: __lockmgr_args: unknown lockmgr request 0x0

-- 
O. Hartmann


pgp5KXIzf0Mtt.pgp
Description: OpenPGP digital signature