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
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 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 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 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 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=0x88a93dFPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX
AMD Features=0xc040MMX+,3DNow!+,3DNow!
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=0x88a93dFPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX
AMD Features=0xc040MMX+,3DNow!+,3DNow!
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: Host to PCI bridge pcibus 0 on motherboard
pci0: PCI bus on pcib0
pci0: encrypt/decrypt, entertainment crypto at device 1.2 (no driver attached)
vr0: VIA VT6105M Rhine III 10/100BaseTX port 0xe100-0xe1ff mem
0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0
vr0: Quirks: 0x2
vr0: Revision: 0x96
miibus0: MII bus on vr0
ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr0: Ethernet address: 00:00:24:cc:93:44
vr0: [ITHREAD]
vr1: VIA VT6105M Rhine III 10/100BaseTX port 0xe200-0xe2ff mem
0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0
vr1: Quirks: 0x2
vr1: Revision: 0x96
miibus1: MII bus on vr1
ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus1
ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr1: Ethernet address: 00:00:24:cc:93:45
vr1: [ITHREAD]
vr2: VIA VT6105M Rhine III 10/100BaseTX port 0xe300-0xe3ff mem
0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0
vr2: Quirks: 0x2
vr2: Revision: 0x96
miibus2: MII bus on vr2
ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus2
ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr2: Ethernet address: 00:00:24:cc:93:46
vr2: [ITHREAD]
vr3: VIA VT6105M Rhine III 10/100BaseTX port 0xe400-0xe4ff mem
0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0
vr3: Quirks: 0x2
vr3: Revision: 0x96
miibus3: MII bus on vr3
ukphy3: Generic IEEE 802.3u media interface PHY 1 on miibus3
ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr3: Ethernet address: 00:00:24:cc:93:47
vr3: [ITHREAD]
isab0: PCI-ISA bridge at device 20.0 on pci0
isa0: ISA bus on isab0
atapci0: AMD CS5536 UDMA100 controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 20.2 on pci0
ata0: ATA channel 0 on atapci0
ata0: [ITHREAD]
ata1: ATA channel 1 on atapci0
ata1: [ITHREAD]
ohci0: OHCI (generic) USB controller mem 0xa0005000-0xa0005fff irq 15 at
device 21.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: OHCI (generic) USB controller on ohci0
usb0: USB revision 1.0
uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0
uhub0: 4 ports with 4 removable, self powered
ehci0: AMD CS5536 (Geode) USB 2.0 controller mem 0xa0006000-0xa0006fff irq 15
at device 21.1 on pci0
ehci0: [GIANT-LOCKED]
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: 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
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 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
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 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.confapropos=0sektion=0manpath=FreeBSD+4.5-stableformat=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. 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 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
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
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
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
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/
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
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.
