Re: WITH_CTF breaks CD loader: "File too big"
Warner Losh wrote:
> On Mon, Dec 3, 2018 at 11:14 AM Yuri Pankov wrote:
>
>> Warner Losh wrote:
>>> On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov wrote:
>>>
Yuri Pankov wrote:
> Warner Losh wrote:
>> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote:
>>
>>>
>>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin >>
>>> wrote:
>>>
On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
> Hi,
>
> Building disc1.iso using `make release` and having WITH_CTF set in
> src.conf leads to "File too big" displayed when booting the image.
>
> Would it make sense to build loader and related parts without CTF
> unconditionally as it doesn't look useful there?
>
Fully agree with you
>>>
>>> What a great Idea. We already turn it off in defs.mk:
>
> Sorry about that, I incorrectly assumed it wasn't done yet as there was
> a difference for me.
>
>>> MK_CTF= no
>>>
>>> which should be global to every single Makefile under stand. I'm not
sure
>>> why that's turning it back on.
>>>
>>
>> % cat /etc/src.conf
>> WITH_CTF=yes
>> FRED=present
>> % cd stand/cdboot
>> % make -V MK_CTF
>> no
>> % make -V FRED
>> present
>> %
>>
>> So this sure sounds like a false positive to me. Do you have logs
showing
>> cdboot building with MK_CTF=yes?
>
> Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
> ctfconvert calls in the latter case. Attached is the diff of binary
> sizes in obj/ for stand/i386; could one of those be the problem I'm
seeing?
If ctfconvert calls are indeed the source of problem, then something
seems to be wrong here (I didn't mention the "cdboot" binary exactly,
rather the binary it's trying to load):
yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
no
yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
CTFCONVERT_CMD
no
ctfconvert -L VERSION ${.TARGET}
>>>
>>> Ding! We have a winner: order of operations not quite right. We included
>>> src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD and
>> then
>>> we change the MK_CTF value which has no effect. Unlike the lazy
>> evaluation
>>> in makefile rules, where the last one wins, when we're parsing stuff for
>>> .if, it's the current value that's used. The solution is to include
>>> src.opts.mk later after we set the MK_foo overrides.
>>>
>>> r341433 should fix that.
>>
>> Thank you.
>>
>
> Please give it a spin and let me know if we're golden. I'll MFC it then
> since this should be in 12.1.
Done. Everything looks good now - having clean /usr/obj/; world/kernel
built with WITH_CTF= in /etc/src.conf; successfully booted the disc1.iso
built using `make cdrom`.
signature.asc
Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
On Mon, Dec 3, 2018 at 11:14 AM Yuri Pankov wrote:
> Warner Losh wrote:
> > On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov wrote:
> >
> >> Yuri Pankov wrote:
> >>> Warner Losh wrote:
> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote:
>
> >
> > On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin >
> > wrote:
> >
> >> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
> >>> Hi,
> >>>
> >>> Building disc1.iso using `make release` and having WITH_CTF set in
> >>> src.conf leads to "File too big" displayed when booting the image.
> >>>
> >>> Would it make sense to build loader and related parts without CTF
> >>> unconditionally as it doesn't look useful there?
> >>>
> >>
> >> Fully agree with you
> >>
> >
> > What a great Idea. We already turn it off in defs.mk:
> >>>
> >>> Sorry about that, I incorrectly assumed it wasn't done yet as there was
> >>> a difference for me.
> >>>
> > MK_CTF= no
> >
> > which should be global to every single Makefile under stand. I'm not
> >> sure
> > why that's turning it back on.
> >
>
> % cat /etc/src.conf
> WITH_CTF=yes
> FRED=present
> % cd stand/cdboot
> % make -V MK_CTF
> no
> % make -V FRED
> present
> %
>
> So this sure sounds like a false positive to me. Do you have logs
> >> showing
> cdboot building with MK_CTF=yes?
> >>>
> >>> Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
> >>> ctfconvert calls in the latter case. Attached is the diff of binary
> >>> sizes in obj/ for stand/i386; could one of those be the problem I'm
> >> seeing?
> >>
> >> If ctfconvert calls are indeed the source of problem, then something
> >> seems to be wrong here (I didn't mention the "cdboot" binary exactly,
> >> rather the binary it's trying to load):
> >>
> >> yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
> >> no
> >>
> >> yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
> >> CTFCONVERT_CMD
> >> no
> >> ctfconvert -L VERSION ${.TARGET}
> >>
> >
> > Ding! We have a winner: order of operations not quite right. We included
> > src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD and
> then
> > we change the MK_CTF value which has no effect. Unlike the lazy
> evaluation
> > in makefile rules, where the last one wins, when we're parsing stuff for
> > .if, it's the current value that's used. The solution is to include
> > src.opts.mk later after we set the MK_foo overrides.
> >
> > r341433 should fix that.
>
> Thank you.
>
Please give it a spin and let me know if we're golden. I'll MFC it then
since this should be in 12.1.
Warner
___
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: WITH_CTF breaks CD loader: "File too big"
Warner Losh wrote:
> On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov wrote:
>
>> Yuri Pankov wrote:
>>> Warner Losh wrote:
On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote:
>
> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin
> wrote:
>
>> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
>>> Hi,
>>>
>>> Building disc1.iso using `make release` and having WITH_CTF set in
>>> src.conf leads to "File too big" displayed when booting the image.
>>>
>>> Would it make sense to build loader and related parts without CTF
>>> unconditionally as it doesn't look useful there?
>>>
>>
>> Fully agree with you
>>
>
> What a great Idea. We already turn it off in defs.mk:
>>>
>>> Sorry about that, I incorrectly assumed it wasn't done yet as there was
>>> a difference for me.
>>>
> MK_CTF= no
>
> which should be global to every single Makefile under stand. I'm not
>> sure
> why that's turning it back on.
>
% cat /etc/src.conf
WITH_CTF=yes
FRED=present
% cd stand/cdboot
% make -V MK_CTF
no
% make -V FRED
present
%
So this sure sounds like a false positive to me. Do you have logs
>> showing
cdboot building with MK_CTF=yes?
>>>
>>> Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
>>> ctfconvert calls in the latter case. Attached is the diff of binary
>>> sizes in obj/ for stand/i386; could one of those be the problem I'm
>> seeing?
>>
>> If ctfconvert calls are indeed the source of problem, then something
>> seems to be wrong here (I didn't mention the "cdboot" binary exactly,
>> rather the binary it's trying to load):
>>
>> yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
>> no
>>
>> yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
>> CTFCONVERT_CMD
>> no
>> ctfconvert -L VERSION ${.TARGET}
>>
>
> Ding! We have a winner: order of operations not quite right. We included
> src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD and then
> we change the MK_CTF value which has no effect. Unlike the lazy evaluation
> in makefile rules, where the last one wins, when we're parsing stuff for
> .if, it's the current value that's used. The solution is to include
> src.opts.mk later after we set the MK_foo overrides.
>
> r341433 should fix that.
Thank you.
signature.asc
Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov wrote:
> Yuri Pankov wrote:
> > Warner Losh wrote:
> >> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote:
> >>
> >>>
> >>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin
> >>> wrote:
> >>>
> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
> > Hi,
> >
> > Building disc1.iso using `make release` and having WITH_CTF set in
> > src.conf leads to "File too big" displayed when booting the image.
> >
> > Would it make sense to build loader and related parts without CTF
> > unconditionally as it doesn't look useful there?
> >
>
> Fully agree with you
>
> >>>
> >>> What a great Idea. We already turn it off in defs.mk:
> >
> > Sorry about that, I incorrectly assumed it wasn't done yet as there was
> > a difference for me.
> >
> >>> MK_CTF= no
> >>>
> >>> which should be global to every single Makefile under stand. I'm not
> sure
> >>> why that's turning it back on.
> >>>
> >>
> >> % cat /etc/src.conf
> >> WITH_CTF=yes
> >> FRED=present
> >> % cd stand/cdboot
> >> % make -V MK_CTF
> >> no
> >> % make -V FRED
> >> present
> >> %
> >>
> >> So this sure sounds like a false positive to me. Do you have logs
> showing
> >> cdboot building with MK_CTF=yes?
> >
> > Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
> > ctfconvert calls in the latter case. Attached is the diff of binary
> > sizes in obj/ for stand/i386; could one of those be the problem I'm
> seeing?
>
> If ctfconvert calls are indeed the source of problem, then something
> seems to be wrong here (I didn't mention the "cdboot" binary exactly,
> rather the binary it's trying to load):
>
> yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
> no
>
> yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
> CTFCONVERT_CMD
> no
> ctfconvert -L VERSION ${.TARGET}
>
Ding! We have a winner: order of operations not quite right. We included
src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD and then
we change the MK_CTF value which has no effect. Unlike the lazy evaluation
in makefile rules, where the last one wins, when we're parsing stuff for
.if, it's the current value that's used. The solution is to include
src.opts.mk later after we set the MK_foo overrides.
r341433 should fix that.
Warner
___
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: WITH_CTF breaks CD loader: "File too big"
Yuri Pankov wrote:
> Warner Losh wrote:
>> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote:
>>
>>>
>>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin
>>> wrote:
>>>
On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
> Hi,
>
> Building disc1.iso using `make release` and having WITH_CTF set in
> src.conf leads to "File too big" displayed when booting the image.
>
> Would it make sense to build loader and related parts without CTF
> unconditionally as it doesn't look useful there?
>
Fully agree with you
>>>
>>> What a great Idea. We already turn it off in defs.mk:
>
> Sorry about that, I incorrectly assumed it wasn't done yet as there was
> a difference for me.
>
>>> MK_CTF= no
>>>
>>> which should be global to every single Makefile under stand. I'm not sure
>>> why that's turning it back on.
>>>
>>
>> % cat /etc/src.conf
>> WITH_CTF=yes
>> FRED=present
>> % cd stand/cdboot
>> % make -V MK_CTF
>> no
>> % make -V FRED
>> present
>> %
>>
>> So this sure sounds like a false positive to me. Do you have logs showing
>> cdboot building with MK_CTF=yes?
>
> Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
> ctfconvert calls in the latter case. Attached is the diff of binary
> sizes in obj/ for stand/i386; could one of those be the problem I'm seeing?
If ctfconvert calls are indeed the source of problem, then something
seems to be wrong here (I didn't mention the "cdboot" binary exactly,
rather the binary it's trying to load):
yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
no
yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
CTFCONVERT_CMD
no
ctfconvert -L VERSION ${.TARGET}
signature.asc
Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
Warner Losh wrote: > On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote: > >> >> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin >> wrote: >> >>> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote: Hi, Building disc1.iso using `make release` and having WITH_CTF set in src.conf leads to "File too big" displayed when booting the image. Would it make sense to build loader and related parts without CTF unconditionally as it doesn't look useful there? >>> >>> Fully agree with you >>> >> >> What a great Idea. We already turn it off in defs.mk: Sorry about that, I incorrectly assumed it wasn't done yet as there was a difference for me. >> MK_CTF= no >> >> which should be global to every single Makefile under stand. I'm not sure >> why that's turning it back on. >> > > % cat /etc/src.conf > WITH_CTF=yes > FRED=present > % cd stand/cdboot > % make -V MK_CTF > no > % make -V FRED > present > % > > So this sure sounds like a false positive to me. Do you have logs showing > cdboot building with MK_CTF=yes? Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of ctfconvert calls in the latter case. Attached is the diff of binary sizes in obj/ for stand/i386; could one of those be the problem I'm seeing? --- siz12018-12-03 18:49:01.764091000 +0300 +++ siz22018-12-03 18:49:39.666198000 +0300 @@ -22,28 +22,28 @@ /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/isoboot/isoboot 14395 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/isoboot/isoboot.8.gz 1324 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/isoboot/isoboot.bin 12553 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/libi386/libi386.a 318926 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/libi386/libi386.a 358146 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader/.depend 213 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader/vers.c 99 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/.depend 212 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th 380928 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th.bin 369808 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th.sym 1213320 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th 598016 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th.bin 584344 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th.sym 1427856 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/vers.c 99 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/.depend 213 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua 434176 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua.bin 422992 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua.sym 1508144 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua 716800 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua.bin 706132 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua.sym 1791284 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/vers.c 99 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/.depend 150 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp 319488 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp.bin 308304 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp.sym 991168 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp 495616 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp.bin 484536 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp.sym 1167400 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/vers.c 99 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/mbr/mbr 512 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pmbr/pmbr 512 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/loader 434176 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/pxeboot 436224 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/loader 716800 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/pxeboot 718848 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/pxeboot.8.gz 2311 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/pxeldr 512 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/zfsboot/zfsboot 262656 signature.asc Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote: > > On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin > wrote: > >> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote: >> > Hi, >> > >> > Building disc1.iso using `make release` and having WITH_CTF set in >> > src.conf leads to "File too big" displayed when booting the image. >> > >> > Would it make sense to build loader and related parts without CTF >> > unconditionally as it doesn't look useful there? >> > >> >> Fully agree with you >> > > What a great Idea. We already turn it off in defs.mk: > > MK_CTF= no > > which should be global to every single Makefile under stand. I'm not sure > why that's turning it back on. > % cat /etc/src.conf WITH_CTF=yes FRED=present % cd stand/cdboot % make -V MK_CTF no % make -V FRED present % So this sure sounds like a false positive to me. Do you have logs showing cdboot building with MK_CTF=yes? Warner ___ 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: WITH_CTF breaks CD loader: "File too big"
On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin wrote: > On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote: > > Hi, > > > > Building disc1.iso using `make release` and having WITH_CTF set in > > src.conf leads to "File too big" displayed when booting the image. > > > > Would it make sense to build loader and related parts without CTF > > unconditionally as it doesn't look useful there? > > > > Fully agree with you > What a great Idea. We already turn it off in defs.mk: MK_CTF= no which should be global to every single Makefile under stand. I'm not sure why that's turning it back on. Warner ___ 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"
Warnings on upgrade from 11.2-RELEASE to 12.0-RC3
Hello, I did a test upgrade from 11.2-RELEASE to 12.-RC3 and got these warnings. They look mostly harmless, but mentioning them in case the installer could do something to suppress them if this is the case. % sudo freebsd-update -r 12.0-RC3 upgrade % sudo freebsd-update install [reboot] % sudo freebsd-update install Password: src component not installed, skipped Installing updates...install: chown 0:0 ///proc: Operation not supported install: chmod 555 ///proc: Operation not supported % grep proc /etc/fstab proc/proc procfs rw 0 0 % sudo freebsd-update install Password: src component not installed, skipped Installing updates...rmdir: ///var/db/etcupdate/current/usr/share/openssl/man/en.ISO8859-1: Directory not empty rmdir: ///var/db/etcupdate/current/usr/share/openssl/man: Directory not empty rmdir: ///var/db/etcupdate/current/usr/share/openssl: Directory not empty rmdir: ///var/db/etcupdate/current/usr/share/man/en.UTF-8: Directory not empty rmdir: ///var/db/etcupdate/current/usr/share/man/en.ISO8859-1: Directory not empty rmdir: ///var/db/etcupdate/current/usr/share/man: Directory not empty I'm fairly certain that I got the /proc warning in the past for 11.0-RC on the same system. Is the installation aware of and handling mountpoints correctly? Likewise the manpages: % ls -l /var/db/etcupdate/current/usr/share/openssl/man/en.ISO8859-1 total 1 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man1 -> ../man1 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man3 -> ../man3 % ls -l /var/db/etcupdate/current/usr/share/man/en.UTF-8 total 5 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man1 -> ../man1 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man2 -> ../man2 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man3 -> ../man3 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man4 -> ../man4 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man5 -> ../man5 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man6 -> ../man6 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man7 -> ../man7 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man8 -> ../man8 lrwxr-xr-x 1 root wheel 7 15 Nov 2014 man9 -> ../man9 broken symlinks (self-referencing) in both cases. Not sure what has made this happen now or at some time in the past, but it's certainly not been due to manual intervention; this system has always been updated via freebsd-update since back to 10.0. Should it be noticing and fixing such broken links? Any ideas what caused them in the first place? Regards, Roger ___ 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: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Mon, 3 Dec 2018 09:26:14 +0100 "O. Hartmann" schrieb: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Fri, 30 Nov 2018 23:14:07 +0900 > Tomoaki AOKI schrieb: > > > On Wed, 28 Nov 2018 19:39:21 +0100 > > "O. Hartmann" wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > Am Wed, 28 Nov 2018 15:00:42 +0100 > > > Emmanuel Vadot schrieb: > > > > > > > Hi, > > > > > > > > On Wed, 28 Nov 2018 10:51:11 +0100 > > > > "O. Hartmann" wrote: > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA512 > > > > > > > > > > I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware > > > > > is latest, > > > > > r1.22 from 2013). The E751 is of model series S26391-K326-V100 and > > > > > equipted with > > > > > a Core i5-2520M CPU and supposed to be also equipted with a iGPU HM65 > > > > > according > > > > > to the techniscal specifications from Fujitsu. > > > > > > > > > > Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most > > > > > recent I could > > > > > grap from the download page), the screen becomes distorted > > > > > immediately after the > > > > > kernel has loaded and initialised/booted. The screen is at the > > > > > loader's all > > > > > right so far. > > > > > > > > > > Trying to disable graphics mode via escaping to the loader's prompt > > > > > and setting > > > > > > > > > > set hw.vga.textmode=1 > > > > > > > > > > subsequently loading the kernel and then booting, doesn't help. The > > > > > screen is > > > > > distorted again. The notebook seems UEFI only and doesn't boot off > > > > > from MBR > > > > > partioned devices (i.e. NanoBSD I used to use). > > > > > > > > > > Loading /boot/kernel/i915kms.ko > > > > > > > > > > after manually having loaded /boot/kernel/kernel (and not booted yet) > > > > > doesn't > > > > > change anything either. > > > > > > > > > > Booting off and installing Linux (Ubuntu, Mint so far, most revent > > > > > verions I can > > > > > get my hands on) is no problem. The console works fine from the > > > > > beginning and so > > > > > the graphics. > > > > > > > > > > Is there a chance to get a FreeBSD booting the easy way? > > > > > > > > > > The provided boot images do not contain any of the > > > > > graphics/drm-stable|next|legacy-kmod stuff, I tried to load > > > > > i915kms.ko off > > > > > from /boot/modules/ (were those modules from the ports are supposed > > > > > to reside) > > > > > but no chance. > > > > > > > > > > Before starting investigating this issue further I'd like to ask > > > > > wether there > > > > > is a general support provided or is that type of notebook dead matter > > > > > for > > > > > FreeBSD of the modern kind? > > > > > > > > > > Thanks in advance, > > > > > > > > > > oh > > > > > > > > > > p.s. please CC me, I'm not subscribing all lists. > > > > > > > > > > - -- > > > > > O. Hartmann > > > > > -BEGIN PGP SIGNATURE- > > > > > > > > > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY > > > > > lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP > > > > > /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf > > > > > vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg > > > > > =XD7b > > > > > -END PGP SIGNATURE- > > > > > > > > Could you post a picture somewhere ? > > > > > > > > I have a laptop which have efifb problem, what I need to do is (at > > > > loader prompt) : > > > > > > > > gop set 4 (to switch to a different mode) > > > > gop set 0 (switch to the correct mode) > > > > > > > > You can gop list (iirc) to checks the available mode. > > > > > > > > The problem is that we are mixing serial and gop in loader.efi and > > > > when you set one mode in serial (or for SIMPLE_TEXT_PROTOCOL) is can > > > > mess the graphical mode. > > > > > > > > > > Sorry, I have no upload place to put some screenshots. > > > > > > The natural resolution of the display is 1280x800 pixel. > > > > > > When existing to the loader and issuing as recommended the command "gop > > > list", I get > > > three modes: > > > > > > mode 0: 1024x768x32, stride=1024 > > > mode 1: 640x480x32, stride=640 > > > mode 2: 800x600x32, stride=800 > > > > > > Setting mode 1 and 2 via gop set X solves the problem and the screen is, > > > at least > > > during a live session of the latest 12-PRE USB image, readable and > > > looking normal. > > > > > > As soon as I have an installation media, I'll check whether the screen is > > > operable > > > after installation (and, of course, loader settings as required), or not. > > > > > > > Hi. > > > > So you can try > > efi_max_resolution="800x600" > > or > > efi_max_resolution="640x480" > > in /etc/loader.conf. > > > > See /etc/defaults/loader.conf for more info. > > The loader.conf man page doesn't show what's the default value. > [...] > > Tha
Re: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Fri, 30 Nov 2018 23:14:07 +0900 Tomoaki AOKI schrieb: > On Wed, 28 Nov 2018 19:39:21 +0100 > "O. Hartmann" wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Am Wed, 28 Nov 2018 15:00:42 +0100 > > Emmanuel Vadot schrieb: > > > > > Hi, > > > > > > On Wed, 28 Nov 2018 10:51:11 +0100 > > > "O. Hartmann" wrote: > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA512 > > > > > > > > I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware > > > > is latest, > > > > r1.22 from 2013). The E751 is of model series S26391-K326-V100 and > > > > equipted with > > > > a Core i5-2520M CPU and supposed to be also equipted with a iGPU HM65 > > > > according > > > > to the techniscal specifications from Fujitsu. > > > > > > > > Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent > > > > I could > > > > grap from the download page), the screen becomes distorted immediately > > > > after the > > > > kernel has loaded and initialised/booted. The screen is at the loader's > > > > all right > > > > so far. > > > > > > > > Trying to disable graphics mode via escaping to the loader's prompt and > > > > setting > > > > > > > > set hw.vga.textmode=1 > > > > > > > > subsequently loading the kernel and then booting, doesn't help. The > > > > screen is > > > > distorted again. The notebook seems UEFI only and doesn't boot off from > > > > MBR > > > > partioned devices (i.e. NanoBSD I used to use). > > > > > > > > Loading /boot/kernel/i915kms.ko > > > > > > > > after manually having loaded /boot/kernel/kernel (and not booted yet) > > > > doesn't > > > > change anything either. > > > > > > > > Booting off and installing Linux (Ubuntu, Mint so far, most revent > > > > verions I can > > > > get my hands on) is no problem. The console works fine from the > > > > beginning and so > > > > the graphics. > > > > > > > > Is there a chance to get a FreeBSD booting the easy way? > > > > > > > > The provided boot images do not contain any of the > > > > graphics/drm-stable|next|legacy-kmod stuff, I tried to load i915kms.ko > > > > off > > > > from /boot/modules/ (were those modules from the ports are supposed to > > > > reside) > > > > but no chance. > > > > > > > > Before starting investigating this issue further I'd like to ask wether > > > > there is a > > > > general support provided or is that type of notebook dead matter for > > > > FreeBSD of > > > > the modern kind? > > > > > > > > Thanks in advance, > > > > > > > > oh > > > > > > > > p.s. please CC me, I'm not subscribing all lists. > > > > > > > > - -- > > > > O. Hartmann > > > > -BEGIN PGP SIGNATURE- > > > > > > > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY > > > > lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP > > > > /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf > > > > vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg > > > > =XD7b > > > > -END PGP SIGNATURE- > > > > > > Could you post a picture somewhere ? > > > > > > I have a laptop which have efifb problem, what I need to do is (at > > > loader prompt) : > > > > > > gop set 4 (to switch to a different mode) > > > gop set 0 (switch to the correct mode) > > > > > > You can gop list (iirc) to checks the available mode. > > > > > > The problem is that we are mixing serial and gop in loader.efi and > > > when you set one mode in serial (or for SIMPLE_TEXT_PROTOCOL) is can > > > mess the graphical mode. > > > > > > > Sorry, I have no upload place to put some screenshots. > > > > The natural resolution of the display is 1280x800 pixel. > > > > When existing to the loader and issuing as recommended the command "gop > > list", I get > > three modes: > > > > mode 0: 1024x768x32, stride=1024 > > mode 1: 640x480x32, stride=640 > > mode 2: 800x600x32, stride=800 > > > > Setting mode 1 and 2 via gop set X solves the problem and the screen is, at > > least > > during a live session of the latest 12-PRE USB image, readable and looking > > normal. > > > > As soon as I have an installation media, I'll check whether the screen is > > operable > > after installation (and, of course, loader settings as required), or not. > > Hi. > > So you can try > efi_max_resolution="800x600" > or > efi_max_resolution="640x480" > in /etc/loader.conf. > > See /etc/defaults/loader.conf for more info. > The loader.conf man page doesn't show what's the default value. [...] Thank you very much. Setting those values in loader.conf (800x600, 1024x768 fails and leaves me with a distorted screen) make the console work again also for a installed FreeBSD 12+ (UEFI boot). The "distortion" can be described as follows (maybe a hint): the screen seems "chunked", means there are ideas of rows and columns, and the square the intersections define, have horizontal and vertical lines, like a
