Processed (with 1 errors): Re: Booting from zfs root seems to not work 8.3 and 10.0 however work
Processing commands for cont...@bugs.debian.org: > retitle 651624 sometimes device nodes disappear after a reboot, making Bug #651624 [kfreebsd-image-9-amd64] Booting from zfs root seems to not work 8.3 and 10.0 however work Changed Bug title to 'sometimes device nodes disappear after a reboot, making' from 'Booting from zfs root seems to not work 8.3 and 10.0 however work' > them inaccessible to root file system Unknown command or malformed arguments to command. > thanks Stopping processing here. Please contact me if you need assistance. -- 651624: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651624 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133469280020708.transcr...@bugs.debian.org
Re: Booting broken with debian-installer
On Thu, Mar 18, 2010 at 06:23:19PM +0100, Philipp Kern wrote: > -amd64 daily instead hangs on boot at: > "Setting up filesystem, please wait ... > GEOM_LABEL: Label ufsid/4ba211726b8b4567 removed." That one can be solved by activating the IO-APIC, fwiw. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100318172743.ga11...@kelgar.0x539.de
Re: Booting broken with debian-installer
Hi, On Thu, Mar 18, 2010 at 05:45:14PM +0100, Philipp Kern wrote: > it seems that something broke between the daily images 20100306-1120 > and 20100307-1120. grub spits out "error: only ELF kernel supports > module.". That means booting the installer is broken with 0307 onwards. further testing revealed: this only affects kfreebsd-i386, not the -amd64 flavour, at least not in the daily image. (0312 was likewise broken.) kfreebsd-i386's 20100306 also aborts with "Configuring bootstrap-base failed with error code 1." during installation. -amd64 daily instead hangs on boot at: "Setting up filesystem, please wait ... GEOM_LABEL: Label ufsid/4ba211726b8b4567 removed." That's all with VirtualBox, too. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100318172319.ga10...@kelgar.0x539.de
Re: booting on the soekris serial console
Hi all,
So I was able to boot my soekris machine on Debian GNU/kFreeBSD. The two
key points were to setup the console to be at 9600 baud and use the 486
kernel instead of the stock 686 kernel, which doesn't boot:
Loading kernel of FreeBSD 7.2-1-686 ...
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
#0 Fri Jan 15 18:15:20 UTC 2010
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Geode(TM) Integrated Processor by AMD PCS (Unknown-class CPU)
Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2
Features=0x88a93d
AMD Features=0xc040
panic: CPU class not configured
Uptime: 1s
So I removed the stock kernel and installed kfreebsd-image-7-486, then
setup the serial console in /etc/grub.d/40_custom:
menuentry "Debian GNU/kFreeBSD, with kFreeBSD 7.2-1-486" {
insmod ufs2
insmod bsd
set root=(hd0,1)
search --no-floppy --fs-uuid --set 4b81dce84e75710d
echoLoading kernel of FreeBSD 7.2-1-486 ...
kfreebsd/boot/kfreebsd-7.2-1-486.gz -D -h
kfreebsd_module_elf /lib/modules/7.2-1-486/acpi.ko
set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ad0s1
set kFreeBSD.vfs.root.mountfrom.options=rw
}
Then set that kernel to be the default one:
GRUB_DEFAULT=1
in /etc/default/grub.
Then I can connect to the serial console using a command like:
cu -l /dev/ttyS0 -s 9600
and victory is mine!
GNU/kFreeBSD roadkiller 7.2-1-486 #0 Fri Jan 15 17:03:43 UTC 2010 i586 i386
Geode(TM) Integrated Processor by AMD PCS GNU/kFreeBSD
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
#0 Fri Jan 15 17:03:43 UTC 2010
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU)
Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2
Features=0x88a93d
AMD Features=0xc040
real memory = 536870912 (512 MB)
avail memory = 515928064 (492 MB)
kbd1 at kbdmux0
K6-family MTRR support enabled (2 registers)
ACPI Error (tbxfroot-0308): A valid RSDP was not found [20070320]
ACPI: Table initialisation failed: AE_NOT_FOUND
ACPI: Try disabling either ACPI or apic support.
pcib0: pcibus 0 on motherboard
pci0: on pcib0
pci0: at device 1.2 (no driver attached)
vr0: port 0xe100-0xe1ff mem
0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0
vr0: Quirks: 0x2
vr0: Revision: 0x96
miibus0: on vr0
ukphy0: PHY 1 on miibus0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr0: Ethernet address: 00:00:24:cc:93:44
vr0: [ITHREAD]
vr1: port 0xe200-0xe2ff mem
0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0
vr1: Quirks: 0x2
vr1: Revision: 0x96
miibus1: on vr1
ukphy1: PHY 1 on miibus1
ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr1: Ethernet address: 00:00:24:cc:93:45
vr1: [ITHREAD]
vr2: port 0xe300-0xe3ff mem
0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0
vr2: Quirks: 0x2
vr2: Revision: 0x96
miibus2: on vr2
ukphy2: PHY 1 on miibus2
ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr2: Ethernet address: 00:00:24:cc:93:46
vr2: [ITHREAD]
vr3: port 0xe400-0xe4ff mem
0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0
vr3: Quirks: 0x2
vr3: Revision: 0x96
miibus3: on vr3
ukphy3: PHY 1 on miibus3
ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr3: Ethernet address: 00:00:24:cc:93:47
vr3: [ITHREAD]
isab0: at device 20.0 on pci0
isa0: on isab0
atapci0: port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 20.2 on pci0
ata0: on atapci0
ata0: [ITHREAD]
ata1: on atapci0
ata1: [ITHREAD]
ohci0: mem 0xa0005000-0xa0005fff irq 15 at
device 21.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: on ohci0
usb0: USB revision 1.0
uhub0: on usb0
uhub0: 4 ports with 4 removable, self powered
ehci0: mem 0xa0006000-0xa0006fff irq 15
at device 21.1 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb1: EHCI version 1.0
usb1: companion controller, 4 ports each: usb0
usb1: on ehci0
usb1: USB revision 2.0
uhub1: on usb1
uhub1: 4 ports with 4 removable, self powered
cpu0 on motherboard
pmtimer0 on isa0
orm0: at iomem 0xc8000-0xd27ff pnpid ORM on isa0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio0: [FILTER]
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio1: [FILTER]
ppc0: parallel port not found.
Timecounter "TSC" frequency 499905104 Hz quality 800
Timecounters tick every 1.000 msec
ad0: 3919MB at ata0-master WDM
Re: booting on the serial console
On Wed, Mar 03, 2010 at 01:44:05PM -0700, Joey Korkames wrote:
>> Usually, in BSD, you pass -P or -h to the /boot/loader in boot.config.
>> But since that loader is now completely bypassed in the boot process,
>> that doesn't work. I haven't found in the FreeBSD documentation what
>> -P/-h actually *does* at the machine level, or rather if it passes
>> "commandline" arguments to the kernel or what not.
>>
>> Basically, I need to do two things:
>>
>> 1. i need to enable the serial console. this is usually done at the
>> loader level, with the -h flag, or at compile time, using the 0x30 flag
>> on the sio driver
>
> In /boot/grub/grub.cfg, I use:
>
> menuentry "FreeBSD:blockdev_fs:da0s1a" {
>insmod bsd
>echo "Loading kernel: /boot/kernel/kernel ..."
>kfreebsd /boot/kernel/kernel -D -h
>kfreebsd_loadenv /boot/device.hints
>set kFreeBSD.vfs.root.mountfrom=:/dev/da0s1a
>echo "Booting: FreeBSD:blockdev_fs:da0s1a"
> }
>
> If you go to the GRUB2 command prompt (ESC key) and type "kfreebsd
> --help", you'll get a listing of all supported boot options, mostly
> corresponding with http://www.freebsd.org/cgi/man.cgi?query=boot
Excellent tip! Thanks! I didn't expect anybody to be as crazy as me at
this point... ;)
Unfortunately, that doesn't seem to be working: everything still seems
to be blocked... This is my grub.conf entry:
+--+
| insmod ufs2 |
| insmod bsd |
| set root=(hd0,1) |
| search --no-floppy --fs-uuid --set 4b81dce84e75710d |
| echo Loading kernel of FreeBSD 7.2-1-686 ... |
| kfreebsd /boot/kfreebsd-7.2-1-686.gz -D -h |
| kfreebsd_module_elf /lib/modules/7.2-1-686/acpi.ko |
| kfreebsd_loadenv /boot/device.hints |
| set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ad0s1 |
| set kFreeBSD.vfs.root.mountfrom.options=rw |
+--+
(As seen from the grub prompt.)
I tried reconnecting to the console in 9600 baud, no luck either...
Maybe the problem is with the bitrate, but I feel the kernel just
freezes because i don't see disk activity and the machine doesn't seek
an IP through DHCP...
>> 2. i need to specify the speed of the port. this is usually done in
>> config options or at compile time.
>
> I have had very little luck with this. Usually when something in the freebsd
> documentations says that you can change baud rate at runtime with a flag,
> I find that I have to recompile the relevant code with a macro or
> env-variable changed.
> I end up sticking with the 9600 baud default.
Yeah, that's probably a better idea... Unfortunately, the default
bitrate on the soekris is this odd 19200 thing, so the BIOS appears
there only.. I'll try to turn everything to 9600.
>> I tried setting hint.sio.0.flags="0x30" along with the other environment
>> in grub, without any luck.
>
> Note the kfreebsd_loadenv on device.hints above, without it sio() (or uart()
> for FreeBSD 8)
> won't start on the serial port and you won't get a console.
> You can try setting your flags in there to see if you can change the baud
> rate.
Yay! So how do I recompile *that* kernel now? :)
>> Is there any way I can just
>> revert back to the regular /boot/loader quickly?
>
> In /boot/grub/grub.cfg, I use:
>
> menuentry "BTX client: /boot/freebsd/loader" {
>insmod bsd
>echo "Loading btx client: /boot/freebsd/loader ..."
>kfreebsd /boot/freebsd/loader -D -h
>echo "Booting: BTX client: /boot/freebsd/loader"
> }
Hum... I don't seem to have /boot/freebsd/loader (or /boot/freebsd/ for
that matter), in which package is it now?
Thanks a lot for answering!
A.
--
Antoine Beaupré
Réseau Koumbit Networks
+1.514.387.6262
signature.asc
Description: Digital signature
Re: booting on the serial console
Usually, in BSD, you pass -P or -h to the /boot/loader in boot.config.
But since that loader is now completely bypassed in the boot process,
that doesn't work. I haven't found in the FreeBSD documentation what
-P/-h actually *does* at the machine level, or rather if it passes
"commandline" arguments to the kernel or what not.
Basically, I need to do two things:
1. i need to enable the serial console. this is usually done at the
loader level, with the -h flag, or at compile time, using the 0x30 flag
on the sio driver
In /boot/grub/grub.cfg, I use:
menuentry "FreeBSD:blockdev_fs:da0s1a" {
insmod bsd
echo "Loading kernel: /boot/kernel/kernel ..."
kfreebsd /boot/kernel/kernel -D -h
kfreebsd_loadenv /boot/device.hints
set kFreeBSD.vfs.root.mountfrom=:/dev/da0s1a
echo "Booting: FreeBSD:blockdev_fs:da0s1a"
}
If you go to the GRUB2 command prompt (ESC key) and type "kfreebsd --help",
you'll get a listing of all supported boot options, mostly corresponding
with http://www.freebsd.org/cgi/man.cgi?query=boot
2. i need to specify the speed of the port. this is usually done in
config options or at compile time.
I have had very little luck with this. Usually when something in the freebsd
documentations says that you can change baud rate at runtime with a flag, I find
that I have to recompile the relevant code with a macro or env-variable changed.
I end up sticking with the 9600 baud default.
I tried setting hint.sio.0.flags="0x30" along with the other environment
in grub, without any luck.
Note the kfreebsd_loadenv on device.hints above, without it sio() (or uart()
for FreeBSD 8)
won't start on the serial port and you won't get a console.
You can try setting your flags in there to see if you can change the baud rate.
Is there any way I can just
revert back to the regular /boot/loader quickly?
In /boot/grub/grub.cfg, I use:
menuentry "BTX client: /boot/freebsd/loader" {
insmod bsd
echo "Loading btx client: /boot/freebsd/loader ..."
kfreebsd /boot/freebsd/loader -D -h
echo "Booting: BTX client: /boot/freebsd/loader"
}
HTH
-joey
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cone.1267649045.671132.3486.1...@toolshiner.phx1.kidfixit.com
Re: Booting
In article <[EMAIL PROTECTED]> you write: > >It doesn't matter what GRUB includes, the thing which matters if the >FreeBSD bootloader and kernel can be modified to use the multiboot >specification. I think that's possible. It would be nice. >Miltiboot does support passing modules. The actual linkage (like >symbol lookups etc) should be done in the kernel, because this is >kernel-dependent. But I think this is already the case, isn't it? Presumably by "passing" you mean that the loader loads the modules rather than just passin their filenames (otherwise you wouldn't be able to boot off a device whose driver is in a module). In which case I don't see any technical obstacles. Tony.
Re: Booting
On Tue, Mar 19, 2002 at 02:27:47AM +, Tony Finch wrote: > In article <[EMAIL PROTECTED]> you write: > > > >Reading quickly the things supported, I think those things can be > >passed from the loader to the kernel using the multiboot > >specification. FreeBSD doesn't need to abandon its bootloader and the > >way of doing things, just change it to use the multiboot > >specification. That way you could use the FreeBSD loader for every > >kernel and every multiboot-compliant bootloader for the FreeBSD kernel. > > You should be reading the man pages for the -CURRENT boot loader, > because it has changed significantly since 4.X. The loader is > responsible for: I think the multiboot standard is flexible enough. If it isn't, we should change it IMHO. :) > (1) passing boot flags for things like single-user mode, etc. This is supported. > (2) passing environment variables, such as boot-time tunables > (size of static data structures in the kernel etc.) and > unprobeable device information (mostly for non-PnP ISA). > (The latter is new in -CURRENT.) This is also possible. > (3) pre-linking modules into the kernel; the kernel itself > doesn't have to include all the drivers needed to boot > on a machine. > > Does GRUB include a linker? It doesn't matter what GRUB includes, the thing which matters if the FreeBSD bootloader and kernel can be modified to use the multiboot specification. I think that's possible. Miltiboot does support passing modules. The actual linkage (like symbol lookups etc) should be done in the kernel, because this is kernel-dependent. But I think this is already the case, isn't it? (Sorry, no time to find it out) Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpE0SXcKOVnC.pgp Description: PGP signature
Re: Booting
In article <[EMAIL PROTECTED]> you write: > >Reading quickly the things supported, I think those things can be >passed from the loader to the kernel using the multiboot >specification. FreeBSD doesn't need to abandon its bootloader and the >way of doing things, just change it to use the multiboot >specification. That way you could use the FreeBSD loader for every >kernel and every multiboot-compliant bootloader for the FreeBSD kernel. You should be reading the man pages for the -CURRENT boot loader, because it has changed significantly since 4.X. The loader is responsible for: (1) passing boot flags for things like single-user mode, etc. (2) passing environment variables, such as boot-time tunables (size of static data structures in the kernel etc.) and unprobeable device information (mostly for non-PnP ISA). (The latter is new in -CURRENT.) (3) pre-linking modules into the kernel; the kernel itself doesn't have to include all the drivers needed to boot on a machine. Does GRUB include a linker? Tony.
re: Booting
On Sun, Mar 17, 2002 at 06:55:26PM +0100, Jeroen Dekkers wrote: > This is certainly true. It's a wishlist item, it would be nice if all > free kernels would use multiboot. I've heard that grub will at least > be partly rewritten to make some new features possible, it might also > be the "extra environmental stuff" but I'm not sure what you mean with > it. It'd be nice, but I think the BSD's are going to be pretty skeptical. FreeBSD, in particular, has a very nice boot loader. I rather like it, it reminds me of OpenBoot. that's because they've included a forth interpreter in the booter... i have these huge conflicting feelings on whether i find that extremely disgusting or extremely cool. :-)
Re: Booting
On Sun, Mar 17, 2002 at 01:07:36PM -0500, [EMAIL PROTECTED] wrote: > On Sun, Mar 17, 2002 at 06:55:26PM +0100, Jeroen Dekkers wrote: > > This is certainly true. It's a wishlist item, it would be nice if all > > free kernels would use multiboot. I've heard that grub will at least > > be partly rewritten to make some new features possible, it might also > > be the "extra environmental stuff" but I'm not sure what you mean with > > it. > > It'd be nice, but I think the BSD's are going to be pretty skeptical. > FreeBSD, in particular, has a very nice boot loader. I rather like it, > it reminds me of OpenBoot. > > The man page for loader.conf describes some of the environment stuff I > mentioned: > http://www.freebsd.org/cgi/man.cgi?query=loader.conf&apropos=0&sektion=0&manpath=FreeBSD+4.5-stable&format=html Reading quickly the things supported, I think those things can be passed from the loader to the kernel using the multiboot specification. FreeBSD doesn't need to abandon its bootloader and the way of doing things, just change it to use the multiboot specification. That way you could use the FreeBSD loader for every kernel and every multiboot-compliant bootloader for the FreeBSD kernel. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpV0Ak6Q3mU9.pgp Description: PGP signature
Re: Booting
On Sun, Mar 17, 2002 at 06:55:26PM +0100, Jeroen Dekkers wrote: > This is certainly true. It's a wishlist item, it would be nice if all > free kernels would use multiboot. I've heard that grub will at least > be partly rewritten to make some new features possible, it might also > be the "extra environmental stuff" but I'm not sure what you mean with > it. It'd be nice, but I think the BSD's are going to be pretty skeptical. FreeBSD, in particular, has a very nice boot loader. I rather like it, it reminds me of OpenBoot. The man page for loader.conf describes some of the environment stuff I mentioned: http://www.freebsd.org/cgi/man.cgi?query=loader.conf&apropos=0&sektion=0&manpath=FreeBSD+4.5-stable&format=html
Re: Booting
On Sun, Mar 17, 2002 at 12:16:46PM -0500, [EMAIL PROTECTED] wrote: > On Sun, Mar 17, 2002 at 05:25:12PM +0100, Jeroen Dekkers wrote: > > I think the best way is to make multiboot BSD kernel images. The > > multiboot standard is very flexible, it's included in the grub > > documentation. > > That would indeed be nice. It also is not something I'm going to waste > my time on. FreeBSD has a bootloader that works just fine. Works a lot > like grub, in fact. However, there is a lot of extra environmental stuff > that it does, and I'm not sure that grub could support that without a > lot of extra code. > > IMHO, this is a case of fixing something that isn't broken. And at this > point in time, it's just not worthwhile. This is certainly true. It's a wishlist item, it would be nice if all free kernels would use multiboot. I've heard that grub will at least be partly rewritten to make some new features possible, it might also be the "extra environmental stuff" but I'm not sure what you mean with it. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpTBovScl11f.pgp Description: PGP signature
Re: Booting
On Sun, Mar 17, 2002 at 05:25:12PM +0100, Jeroen Dekkers wrote: > On Sat, Mar 09, 2002 at 06:30:27PM -0700, Joel Baker wrote: > > Honestly? I'd really love to see GRUB achieve it's nominal purpose - GRand > > Unified Bootloader. Making it capable of compiling on, and booting, *BSD > > machines seems like a major step forward for it, and it shouldn't be all > > that hard - it's just one kernel and one primary filesystem (FFS) to make > > sure function, to support the vast majority of BSD-land. > > I think the best way is to make multiboot BSD kernel images. The > multiboot standard is very flexible, it's included in the grub > documentation. That would indeed be nice. It also is not something I'm going to waste my time on. FreeBSD has a bootloader that works just fine. Works a lot like grub, in fact. However, there is a lot of extra environmental stuff that it does, and I'm not sure that grub could support that without a lot of extra code. IMHO, this is a case of fixing something that isn't broken. And at this point in time, it's just not worthwhile. Maybe once the porting is farther along. For now, I'd rather concentrate on fixing the things that are, in fact, broken. See http://people.debian.org/~utsl/freebsd-i386/status.html for more info. ---Nathan
Re: Booting
On Sat, Mar 09, 2002 at 06:30:27PM -0700, Joel Baker wrote: > Honestly? I'd really love to see GRUB achieve it's nominal purpose - GRand > Unified Bootloader. Making it capable of compiling on, and booting, *BSD > machines seems like a major step forward for it, and it shouldn't be all > that hard - it's just one kernel and one primary filesystem (FFS) to make > sure function, to support the vast majority of BSD-land. I think the best way is to make multiboot BSD kernel images. The multiboot standard is very flexible, it's included in the grub documentation. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpY6MLuhhfCR.pgp Description: PGP signature
Re: Booting
Matthew Garrett <[EMAIL PROTECTED]> writes: > > On Sat, Mar 09, 2002 at 06:30:27PM -0700, Joel Baker wrote: > > > Honestly? I'd really love to see GRUB achieve it's nominal purpose - GRand > > Unified Bootloader. Making it capable of compiling on, and booting, *BSD > > machines seems like a major step forward for it, and it shouldn't be all > > that hard - it's just one kernel and one primary filesystem (FFS) to make > > sure function, to support the vast majority of BSD-land. > > It compiles and boots the kernel, so the only sticking point really is the > passing of kernel options. This is handled for FreeBSD, but not Net or > Open. If anyone has any idea how this is done, implementing it would > certainly be useful. I wouldn't have thought it should be hard to hack into GRUB; OTOH I'm not going to be able to look at it until I get back from Wales (6 weeks time). Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: Booting
On Mon, Mar 11, 2002 at 02:24:55AM +, Tony Finch wrote: > FreeBSD has a directory /boot too (in -STABLE it holds the stage 3 loader > and its configuration, and in -CURRENT i believe the kernel(s) and > modules have moved in there too). So it would seem sensible to make > NetBSD follow the others. (Does NetBSD/i386 not use /usr/mdec any more?) I've been using /boot for the boot loader, and /lib/modules for kernel modules. At present, I have the boot loader packaged together with the kernel, but that may change later. AFAICS, on FreeBSD the paths for kernel, boot loader, modules, etc. are customizable, so I see no reason not to use standard Debian locations. They aren't really that different, and are pretty reasonable.
Re: Booting
On Mon, Mar 11, 2002 at 01:44:14PM +1100, matthew green wrote: > > (i'm not suggesting i'm advocating that netbsd proper will switch > to a /boot dir -- that's someone else's problem. i was mostly > pointing out that the default /boot as a file isn't a problem.) Agreed :-) Tony.
re: Booting
> The NetBSD loader is, unsurprisingly, not subject to this restriction. I'd > be tempted to go with packaging this and using it as our primary boot > mechanism unless anyone objects. The one problem I can think of is that it > stores the bootcode in /boot, which is a directory under Linux systems. Do > we want to leave /boot as a directory and move the BSD bootcode in there > (presumably patching things slightly in the process) or leave it as is? > >the location of "/boot" as a file is pretty irrelevant for i386. when >"installboot" is run, it hard codes the inodes for it into the 2nd >stage loader (biosboot.sym) and reloads it. so when you run installboot >you can simply give it a pathname other than "/boot" and it will use it >when it comes to booting. > >to be honest, i've slowly come to appreciate /boot as a directory. FreeBSD has a directory /boot too (in -STABLE it holds the stage 3 loader and its configuration, and in -CURRENT i believe the kernel(s) and modules have moved in there too). So it would seem sensible to make NetBSD follow the others. (Does NetBSD/i386 not use /usr/mdec any more?) (i'm not suggesting i'm advocating that netbsd proper will switch to a /boot dir -- that's someone else's problem. i was mostly pointing out that the default /boot as a file isn't a problem.) /usr/mdec still exists as always. (though it apparently should be called /usr/mi386 -- /usr/mdec was for DEC [vax] machines, but the name stuck everywhere.)
Re: Booting
In article <[EMAIL PROTECTED]> you write: > > The NetBSD loader is, unsurprisingly, not subject to this restriction. I'd > be tempted to go with packaging this and using it as our primary boot > mechanism unless anyone objects. The one problem I can think of is that it > stores the bootcode in /boot, which is a directory under Linux systems. Do > we want to leave /boot as a directory and move the BSD bootcode in there > (presumably patching things slightly in the process) or leave it as is? > >the location of "/boot" as a file is pretty irrelevant for i386. when >"installboot" is run, it hard codes the inodes for it into the 2nd >stage loader (biosboot.sym) and reloads it. so when you run installboot >you can simply give it a pathname other than "/boot" and it will use it >when it comes to booting. > >to be honest, i've slowly come to appreciate /boot as a directory. FreeBSD has a directory /boot too (in -STABLE it holds the stage 3 loader and its configuration, and in -CURRENT i believe the kernel(s) and modules have moved in there too). So it would seem sensible to make NetBSD follow the others. (Does NetBSD/i386 not use /usr/mdec any more?) Tony.
re: Booting
GRUB appears capable of booting the kernel, but can't pass any kernel options. This appears to include passing the root file system, requiring it to be typed by hand later on. The NetBSD loader is, unsurprisingly, not subject to this restriction. I'd be tempted to go with packaging this and using it as our primary boot mechanism unless anyone objects. The one problem I can think of is that it stores the bootcode in /boot, which is a directory under Linux systems. Do we want to leave /boot as a directory and move the BSD bootcode in there (presumably patching things slightly in the process) or leave it as is? the location of "/boot" as a file is pretty irrelevant for i386. when "installboot" is run, it hard codes the inodes for it into the 2nd stage loader (biosboot.sym) and reloads it. so when you run installboot you can simply give it a pathname other than "/boot" and it will use it when it comes to booting. to be honest, i've slowly come to appreciate /boot as a directory. .mrg.
Re: Booting
On Sat, Mar 09, 2002 at 06:30:27PM -0700, Joel Baker wrote: > Honestly? I'd really love to see GRUB achieve it's nominal purpose - GRand > Unified Bootloader. Making it capable of compiling on, and booting, *BSD > machines seems like a major step forward for it, and it shouldn't be all > that hard - it's just one kernel and one primary filesystem (FFS) to make > sure function, to support the vast majority of BSD-land. It compiles and boots the kernel, so the only sticking point really is the passing of kernel options. This is handled for FreeBSD, but not Net or Open. If anyone has any idea how this is done, implementing it would certainly be useful. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Booting
On Sat, Mar 09, 2002 at 11:28:05PM +, Matthew Garrett wrote: > GRUB appears capable of booting the kernel, but can't pass any kernel > options. This appears to include passing the root file system, requiring > it to be typed by hand later on. > > The NetBSD loader is, unsurprisingly, not subject to this restriction. I'd > be tempted to go with packaging this and using it as our primary boot > mechanism unless anyone objects. The one problem I can think of is that it > stores the bootcode in /boot, which is a directory under Linux systems. Do > we want to leave /boot as a directory and move the BSD bootcode in there > (presumably patching things slightly in the process) or leave it as is? Honestly? I'd really love to see GRUB achieve it's nominal purpose - GRand Unified Bootloader. Making it capable of compiling on, and booting, *BSD machines seems like a major step forward for it, and it shouldn't be all that hard - it's just one kernel and one primary filesystem (FFS) to make sure function, to support the vast majority of BSD-land. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
