Re: CFT: FreeBSD Package Base
On 2019-04-30 17:03, Miroslav Lachman wrote: David Chisnall wrote on 2019/04/30 10:22: On 29/04/2019 21:12, Joe Maloney wrote: With CFT version you chose to build, and package individual components such as sendmail with a port option. That does entirely solve the problem of being able to reinstall sendmail after the fact without a rebuild of the userland (base) port but perhaps base flavors could solve that problem assuming flavors could extend beyond python. This sounds very much like local optimisation. It's now easy to create a custom base image. Great. But how do I express dependencies in ports on a specific base configuration? This is easy if I depend on a specific base package, but how does this work in your model? For example, if I have a package that depends on a library that is an optional part of the base system, how do I express that pkg needs to either refuse to install it, or install a userland pkg that includes that library in place of my existing version as part of the install process? More importantly for the container use case, if I want to take a completely empty jail and do pkg ins nginx (for example), what does the maintainer of the nginx port need to do to express the minimum set of the base system that needs to be installed to allow nginx to work? One of the goals for the pkg base concept was to allow this kind of use case, easily creating a minimal environment required to run a single service. With a monolithic base package set, you're going to need some mechanism other than packages to express the specific base subset package that you need and I think that you need to justify why this mechanism is better than using small individual packages. Will it not be maintainer's nightmare to take care of all the dependencies on the base packages for each port we have in the ports tree? Speaking as a ports maintainer, it will be very annoying. Splitting it into a handful of large ass packages, same as you are presented with during install, would be best. ___ 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: Mount Root fails: r347007
On Wed, May 1, 2019 at 10:04 PM Larry Rosenman wrote: > Upgraded from r346487 to r347007, and when I reboot, I get a mountroot > prompt. If I answer it with the same BootFS I booted from > (zfs:zroot/ROOT/r347007) it continues to boot, and run. > > Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt > > What else do we need? > > I did upgrade the EFI partitions, and the freebsd-boot partitions > and that did *NOT* change anything. > > Ideas? > BIOS or UEFI booting? 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: Mount Root fails: r347007
On 05/02/2019 8:29 am, Warner Losh wrote: On Wed, May 1, 2019 at 10:04 PM Larry Rosenman wrote: Upgraded from r346487 to r347007, and when I reboot, I get a mountroot prompt. If I answer it with the same BootFS I booted from (zfs:zroot/ROOT/r347007) it continues to boot, and run. Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt What else do we need? I did upgrade the EFI partitions, and the freebsd-boot partitions and that did *NOT* change anything. Ideas? BIOS or UEFI booting? 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" UEFI boot. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 ___ 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: Mount Root fails: r347007
On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: > On 05/02/2019 8:29 am, Warner Losh wrote: > > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman wrote: > > > >> Upgraded from r346487 to r347007, and when I reboot, I get a mountroot > >> prompt. If I answer it with the same BootFS I booted from > >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. > >> > >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt > >> > >> What else do we need? > >> > >> I did upgrade the EFI partitions, and the freebsd-boot partitions > >> and that did *NOT* change anything. > >> > >> Ideas? > >> > > > > BIOS or UEFI booting? > > UEFI boot. > So no change to \efi\boot\bootx64.efi (or whatever you are booting? Can you get the output of 'show' in the boot loader? Also, is there a way you can try one or two of the versions in between 346487 and 347007 to try to narrow the changes down a bit? 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: Mount Root fails: r347007
On 05/02/2019 9:24 am, Warner Losh wrote: On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: On 05/02/2019 8:29 am, Warner Losh wrote: > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman wrote: > >> Upgraded from r346487 to r347007, and when I reboot, I get a mountroot >> prompt. If I answer it with the same BootFS I booted from >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. >> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt >> >> What else do we need? >> >> I did upgrade the EFI partitions, and the freebsd-boot partitions >> and that did *NOT* change anything. >> >> Ideas? >> > > BIOS or UEFI booting? UEFI boot. So no change to \efi\boot\bootx64.efi (or whatever you are booting? Can you get the output of 'show' in the boot loader? Also, is there a way you can try one or two of the versions in between 346487 and 347007 to try to narrow the changes down a bit? Warner show output in 4 screenshots: https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ What's the easiest way to try some of the other revisions? And which would you suggest? (I'm set up for meta-mode). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 ___ 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"
Got the same error from gptzfsboot this morning
Toomas: My laptop has been booting up flawlessly since I installed the gptzfsboot file that you sent. It also successfully rebooted from a cold start this morning but I received the same error message just a few minutes ago when powering up again. gptzfsboot: error 1 LBA 18446744072709551608 gptzfsboot: error 1 LBA 1 gptzfsboot: No ZFS pools located, can't boot On my third retry, I was successful. This is the same LBA and error number that I was getting previously. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: Mount Root fails: r347007
On 05/02/2019 9:41 am, Larry Rosenman wrote: On 05/02/2019 9:24 am, Warner Losh wrote: On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: On 05/02/2019 8:29 am, Warner Losh wrote: > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman wrote: > >> Upgraded from r346487 to r347007, and when I reboot, I get a mountroot >> prompt. If I answer it with the same BootFS I booted from >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. >> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt >> >> What else do we need? >> >> I did upgrade the EFI partitions, and the freebsd-boot partitions >> and that did *NOT* change anything. >> >> Ideas? >> > > BIOS or UEFI booting? UEFI boot. So no change to \efi\boot\bootx64.efi (or whatever you are booting? Can you get the output of 'show' in the boot loader? Also, is there a way you can try one or two of the versions in between 346487 and 347007 to try to narrow the changes down a bit? Warner show output in 4 screenshots: https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ What's the easiest way to try some of the other revisions? And which would you suggest? (I'm set up for meta-mode). working with Kyle Evans on IRC, and backing /boot/loader.efi to r346487 lets the system boot normally. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 ___ 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: Mount Root fails: r347007
On Thu, May 2, 2019 at 9:54 AM Larry Rosenman wrote: > On 05/02/2019 9:41 am, Larry Rosenman wrote: > > On 05/02/2019 9:24 am, Warner Losh wrote: > >> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: > >> > >>> On 05/02/2019 8:29 am, Warner Losh wrote: > >>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman > wrote: > >>> > > >>> >> Upgraded from r346487 to r347007, and when I reboot, I get a > mountroot > >>> >> prompt. If I answer it with the same BootFS I booted from > >>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. > >>> >> > >>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt > >>> >> > >>> >> What else do we need? > >>> >> > >>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions > >>> >> and that did *NOT* change anything. > >>> >> > >>> >> Ideas? > >>> >> > >>> > > >>> > BIOS or UEFI booting? > >>> > >>> UEFI boot. > >>> > >> > >> So no change to \efi\boot\bootx64.efi (or whatever you are booting? > >> > >> Can you get the output of 'show' in the boot loader? > >> > >> Also, is there a way you can try one or two of the versions in between > >> 346487 and 347007 to try to narrow the changes down a bit? > >> > >> Warner > > > > show output in 4 screenshots: > > https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ > > > > What's the easiest way to try some of the other revisions? And which > > would > > you suggest? (I'm set up for meta-mode). > working with Kyle Evans on IRC, and backing /boot/loader.efi to r346487 > lets the system boot > normally. > OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set in your successfully booted system with kenv? 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"
Rotating (efi) framebuffer
Hi I have a Lenovo Ideapad where the screen is rotated 90 degrees and I can't rotate it to landscape mode until I'm in X. How many of you are in the same situation and would like a fix? Seeing how development is going with small (tiny) computers it will probably be more and more common with ultra portables having a "phone screen" which most likely is in portrait mode by default. This also applies to embedded and home brew / prototype devices. It would certainly be nice if we could have a boot time parameter that could rotate the framebuffer (just as a data point, I'm pretty sure Linux can do this). How many would be interested in this? Is there anyone working on this atm? Not sure I will have the time to develop this all of my own but thought I'd check the interest at least. Perhaps a GSoC project? Cheers Johannes ___ 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: Mount Root fails: r347007
On 05/02/2019 10:58 am, Warner Losh wrote: On Thu, May 2, 2019 at 9:54 AM Larry Rosenman wrote: On 05/02/2019 9:41 am, Larry Rosenman wrote: > On 05/02/2019 9:24 am, Warner Losh wrote: >> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: >> >>> On 05/02/2019 8:29 am, Warner Losh wrote: >>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman wrote: >>> > >>> >> Upgraded from r346487 to r347007, and when I reboot, I get a mountroot >>> >> prompt. If I answer it with the same BootFS I booted from >>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. >>> >> >>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt >>> >> >>> >> What else do we need? >>> >> >>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions >>> >> and that did *NOT* change anything. >>> >> >>> >> Ideas? >>> >> >>> > >>> > BIOS or UEFI booting? >>> >>> UEFI boot. >>> >> >> So no change to \efi\boot\bootx64.efi (or whatever you are booting? >> >> Can you get the output of 'show' in the boot loader? >> >> Also, is there a way you can try one or two of the versions in between >> 346487 and 347007 to try to narrow the changes down a bit? >> >> Warner > > show output in 4 screenshots: > https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ > > What's the easiest way to try some of the other revisions? And which > would > you suggest? (I'm set up for meta-mode). working with Kyle Evans on IRC, and backing /boot/loader.efi to r346487 lets the system boot normally. OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set in your successfully booted system with kenv? 2 things: r346675 still works, and vfs.root.mountfrom *IS* set. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 ___ 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: Mount Root fails: r347007
On 05/02/2019 11:10 am, Larry Rosenman wrote: On 05/02/2019 10:58 am, Warner Losh wrote: On Thu, May 2, 2019 at 9:54 AM Larry Rosenman wrote: On 05/02/2019 9:41 am, Larry Rosenman wrote: > On 05/02/2019 9:24 am, Warner Losh wrote: >> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: >> >>> On 05/02/2019 8:29 am, Warner Losh wrote: >>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman wrote: >>> > >>> >> Upgraded from r346487 to r347007, and when I reboot, I get a mountroot >>> >> prompt. If I answer it with the same BootFS I booted from >>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. >>> >> >>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt >>> >> >>> >> What else do we need? >>> >> >>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions >>> >> and that did *NOT* change anything. >>> >> >>> >> Ideas? >>> >> >>> > >>> > BIOS or UEFI booting? >>> >>> UEFI boot. >>> >> >> So no change to \efi\boot\bootx64.efi (or whatever you are booting? >> >> Can you get the output of 'show' in the boot loader? >> >> Also, is there a way you can try one or two of the versions in between >> 346487 and 347007 to try to narrow the changes down a bit? >> >> Warner > > show output in 4 screenshots: > https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ > > What's the easiest way to try some of the other revisions? And which > would > you suggest? (I'm set up for meta-mode). working with Kyle Evans on IRC, and backing /boot/loader.efi to r346487 lets the system boot normally. OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set in your successfully booted system with kenv? 2 things: r346675 still works, and vfs.root.mountfrom *IS* set. r346879 does *NOT* work. Stepping back to r346759 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 ___ 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: Mount Root fails: r347007
On 05/02/2019 11:34 am, Larry Rosenman wrote: On 05/02/2019 11:10 am, Larry Rosenman wrote: On 05/02/2019 10:58 am, Warner Losh wrote: On Thu, May 2, 2019 at 9:54 AM Larry Rosenman wrote: On 05/02/2019 9:41 am, Larry Rosenman wrote: > On 05/02/2019 9:24 am, Warner Losh wrote: >> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: >> >>> On 05/02/2019 8:29 am, Warner Losh wrote: >>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman wrote: >>> > >>> >> Upgraded from r346487 to r347007, and when I reboot, I get a mountroot >>> >> prompt. If I answer it with the same BootFS I booted from >>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. >>> >> >>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt >>> >> >>> >> What else do we need? >>> >> >>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions >>> >> and that did *NOT* change anything. >>> >> >>> >> Ideas? >>> >> >>> > >>> > BIOS or UEFI booting? >>> >>> UEFI boot. >>> >> >> So no change to \efi\boot\bootx64.efi (or whatever you are booting? >> >> Can you get the output of 'show' in the boot loader? >> >> Also, is there a way you can try one or two of the versions in between >> 346487 and 347007 to try to narrow the changes down a bit? >> >> Warner > > show output in 4 screenshots: > https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ > > What's the easiest way to try some of the other revisions? And which > would > you suggest? (I'm set up for meta-mode). working with Kyle Evans on IRC, and backing /boot/loader.efi to r346487 lets the system boot normally. OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set in your successfully booted system with kenv? 2 things: r346675 still works, and vfs.root.mountfrom *IS* set. r346879 does *NOT* work. Stepping back to r346759 r346759 *WORKS*. So it's r346879 that breaks it. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 ___ 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: Mount Root fails: r347007
On Thu, May 2, 2019 at 11:40 AM Larry Rosenman wrote: > > On 05/02/2019 11:34 am, Larry Rosenman wrote: > > On 05/02/2019 11:10 am, Larry Rosenman wrote: > >> On 05/02/2019 10:58 am, Warner Losh wrote: > >>> On Thu, May 2, 2019 at 9:54 AM Larry Rosenman wrote: > >>> > On 05/02/2019 9:41 am, Larry Rosenman wrote: > > On 05/02/2019 9:24 am, Warner Losh wrote: > >> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman wrote: > >> > >>> On 05/02/2019 8:29 am, Warner Losh wrote: > >>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman > wrote: > >>> > > >>> >> Upgraded from r346487 to r347007, and when I reboot, I get a > mountroot > >>> >> prompt. If I answer it with the same BootFS I booted from > >>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. > >>> >> > >>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt > >>> >> > >>> >> What else do we need? > >>> >> > >>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions > >>> >> and that did *NOT* change anything. > >>> >> > >>> >> Ideas? > >>> >> > >>> > > >>> > BIOS or UEFI booting? > >>> > >>> UEFI boot. > >>> > >> > >> So no change to \efi\boot\bootx64.efi (or whatever you are booting? > >> > >> Can you get the output of 'show' in the boot loader? > >> > >> Also, is there a way you can try one or two of the versions in between > >> 346487 and 347007 to try to narrow the changes down a bit? > >> > >> Warner > > > > show output in 4 screenshots: > > https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ > > > > What's the easiest way to try some of the other revisions? And which > > would > > you suggest? (I'm set up for meta-mode). > working with Kyle Evans on IRC, and backing /boot/loader.efi to > r346487 > lets the system boot > normally. > > >>> > >>> OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set > >>> in > >>> your successfully booted system with kenv? > >>> > >> > >> 2 things: r346675 still works, and vfs.root.mountfrom *IS* set. > > r346879 does *NOT* work. Stepping back to r346759 > r346759 *WORKS*. So it's r346879 that breaks it. > Hi, Head back to -head and try applying [0] -- this block was accidentally reintroduced, and I wouldn't be surprised if the double-initialization has some weird side effect. [0] https://people.freebsd.org/~kevans/loader.diff ___ 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: Mount Root fails: r347007
On Thu, May 2, 2019 at 11:42 AM Kyle Evans wrote: > > On Thu, May 2, 2019 at 11:40 AM Larry Rosenman wrote: > > > > On 05/02/2019 11:34 am, Larry Rosenman wrote: > > > On 05/02/2019 11:10 am, Larry Rosenman wrote: > > >> On 05/02/2019 10:58 am, Warner Losh wrote: > > >>> On Thu, May 2, 2019 at 9:54 AM Larry Rosenman wrote: > > >>> > > On 05/02/2019 9:41 am, Larry Rosenman wrote: > > > On 05/02/2019 9:24 am, Warner Losh wrote: > > >> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman > > >> wrote: > > >> > > >>> On 05/02/2019 8:29 am, Warner Losh wrote: > > >>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman > > wrote: > > >>> > > > >>> >> Upgraded from r346487 to r347007, and when I reboot, I get a > > mountroot > > >>> >> prompt. If I answer it with the same BootFS I booted from > > >>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run. > > >>> >> > > >>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt > > >>> >> > > >>> >> What else do we need? > > >>> >> > > >>> >> I did upgrade the EFI partitions, and the freebsd-boot > > >>> >> partitions > > >>> >> and that did *NOT* change anything. > > >>> >> > > >>> >> Ideas? > > >>> >> > > >>> > > > >>> > BIOS or UEFI booting? > > >>> > > >>> UEFI boot. > > >>> > > >> > > >> So no change to \efi\boot\bootx64.efi (or whatever you are booting? > > >> > > >> Can you get the output of 'show' in the boot loader? > > >> > > >> Also, is there a way you can try one or two of the versions in > > >> between > > >> 346487 and 347007 to try to narrow the changes down a bit? > > >> > > >> Warner > > > > > > show output in 4 screenshots: > > > https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/ > > > > > > What's the easiest way to try some of the other revisions? And which > > > would > > > you suggest? (I'm set up for meta-mode). > > working with Kyle Evans on IRC, and backing /boot/loader.efi to > > r346487 > > lets the system boot > > normally. > > > > >>> > > >>> OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set > > >>> in > > >>> your successfully booted system with kenv? > > >>> > > >> > > >> 2 things: r346675 still works, and vfs.root.mountfrom *IS* set. > > > r346879 does *NOT* work. Stepping back to r346759 > > r346759 *WORKS*. So it's r346879 that breaks it. > > > > Hi, > > Head back to -head and try applying [0] -- this block was accidentally > reintroduced, and I wouldn't be surprised if the double-initialization > has some weird side effect. > > [0] https://people.freebsd.org/~kevans/loader.diff To round things off: this patch was confirmed working and committed as r347023. ___ 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: Rotating (efi) framebuffer
> Hi > > I have a Lenovo Ideapad where the screen is rotated 90 degrees and I > can't rotate it to landscape mode until I'm in X. How many of you are in > the same situation and would like a fix? Seeing how development is going > with small (tiny) computers it will probably be more and more common > with ultra portables having a "phone screen" which most likely is in > portrait mode by default. This also applies to embedded and home brew / > prototype devices. > > It would certainly be nice if we could have a boot time parameter that > could rotate the framebuffer (just as a data point, I'm pretty sure > Linux can do this). How many would be interested in this? Is there > anyone working on this atm? Not sure I will have the time to develop > this all of my own but thought I'd check the interest at least. Perhaps > a GSoC project? Yes please. > Johannes -- Rod Grimes rgri...@freebsd.org ___ 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"
