Bug#652448: marked as done (panic when booting on a machine with >= 4 GiB of RAM)
Your message dated Tue, 21 Oct 2014 11:33:49 + with message-id and subject line Bug#765606: Removed package(s) from unstable has caused the Debian Bug report #652448, regarding panic when booting on a machine with >= 4 GiB of RAM to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 652448: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652448 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: kfreebsd-image-9.0-0-686 Version: 9.0~svn228246-1 Severity: important kfreebsd-image-9.0-0-686 (and most likely all IA32 flavours that don't use PAE) panics when booting on a machine with 4 GiB of RAM (or more). Possible ways out of this: - Enable PAE for all flavours. There are major drawbacks, see: http://www.freebsd.org/doc/handbook/kernelconfig-config.html - Add additional flavours (which ones? 686, 686-smp ... ? and then which ones to provide with D-I?) - Fail gracefuly and prompt user to either remove RAM or use AMD64 version Please comment! -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kfreebsd-image-9.0-0-686 depends on: ii freebsd-utils 8.1-5 FreeBSD utilities needed for GNU/k ii kldutils 8.1-5 tools for managing kFreeBSD module Versions of packages kfreebsd-image-9.0-0-686 recommends: pn libc0.1-i686 (no description available) kfreebsd-image-9.0-0-686 suggests no packages. --- End Message --- --- Begin Message --- Version: 9.2-2+rm Dear submitter, as the package kfreebsd-9 has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/765606 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)--- End Message ---
Upstart booting on kFreeBSD
Hi, You may be interested to know that we have made some progress on getting Upstart working on Debian/kFreeBSD. We can now boot to a getty: https://lists.ubuntu.com/archives/upstart-devel/2014-January/003010.html Kind regards, James. -- James Hunt #upstart on freenode http://upstart.ubuntu.com/cookbook https://lists.ubuntu.com/mailman/listinfo/upstart-devel -- 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/52d800d5.9010...@ubuntu.com
Bug#721504: booting from zfs fails with "checksum verification failed"
Package: grub-pc
Version: 2.00-18
Severity: grave
Upgrading grub from -15 to -18 causes a immediate boot failure. Grub gets
into rescue mode with "checksum verification failed" and `insmod normal`
fails with the same message. Booting into a live system the zfs imports
just fine and after downgrading grub everything's back to normal.
Christoph
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/da0s1 /mnt/passport ext2fs rw 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="0"
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod zfs
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
else
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
fi
font="/root/@/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_kfreebsd ###
menuentry 'Debian GNU/kFreeBSD' --class debian --class gnu-kfreebsd --class gnu
--class os $menuentry_id_option 'kfreebsd-simple-d610af6cf49f9371' {
insmod part_msdos
insmod zfs
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
else
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
fi
echo'Loading kernel of FreeBSD 10.0-0-amd64 ...'
kfreebsd/root/@/boot/kfreebsd-10.0-0-amd64.gz
kfreebsd_loadenv/root/@/boot/device.hints
insmod part_msdos
insmod zfs
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
else
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
fi
kfreebsd_module_elf /root/@/lib/modules/10.0-0-amd64/opensolaris.ko
insmod part_msdos
insmod zfs
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
else
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
fi
kfreebsd_module /root/@/boot/zfs/zpool.cache
type=/boot/zfs/zpool.cache
insmod part_msdos
insmod zfs
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
else
search --no-floppy --fs-uuid --set=root d610af6cf49f9371
fi
kfreebsd_module_elf /root/@/lib/modules/10.0-0-amd64/zfs.ko
set kFreeBSD.vfs.root.mountfrom=zfs:base/root
set kFreeBSD.vfs.root.mountfrom.options=rw
set kFreeBSD.vfs.zfs.trim_disable=0
set kFreeBSD.kern.hz=100
set kFreeBSD.hint.atrtc.0.clock=0
set kFreeBSD.hint.p4tcc.0.disabled=1
set kFreeBSD.hint.acpi_throttle.0.disabled=1
set kFreeBSD.hint.apic.0.clock=0
}
submenu 'Advanced options for Debian GNU/kFreeBSD' $menuentry_id_option
'kfreebsd-advanced-d610af6cf49f9371' {
menuentry 'Debian GNU/kFreeBSD, with kFreeBSD 10.0-0-amd64' --class
debian --class gnu-kfreebsd --class gnu --class os $menuentry_id_option
'kfreebsd-10.0-0-amd64-advanced-d610af6cf49f9371' {
insmod part_msdos
insmod zfs
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root d610af6cf49f937
Processed: Re: Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Processing commands for cont...@bugs.debian.org: > tags 651624 + upstream Bug #651624 [kfreebsd-image-9-amd64] sometimes device nodes disappear after a reboot, making Added tag(s) upstream. > forwarded 651624 http://www.freebsd.org/cgi/query-pr.cgi?pr=175179 Bug #651624 [kfreebsd-image-9-amd64] sometimes device nodes disappear after a reboot, making Set Bug forwarded-to-address to 'http://www.freebsd.org/cgi/query-pr.cgi?pr=175179'. > 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.135782408222571.transcr...@bugs.debian.org
Re: Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
On 06/01/13 03:58, Steven Chamberlain wrote: > I think it might have to do with devices in the zpool being renamed [...] > Furthermore, there is a particular problem when ZFS is on a partition, > rather than a whole device, and if that partition extends to the end of > the disk. > If both ada0 and ada1 are renumbered, I instead get the "failed with > error 6" at boot. Well, I've tried moving my ZFS partitions back from the end of the disks (one half of the mirror at a time) and I zeroed the free space until the end of the disk. I'm no longer seeing this problem when device paths are renumbered. > I guess it tries /dev/ada3 *before* > looking at /dev/ada3s3, attempts to import the pool that way, but is > unable to properly read ada3 so marks the drive UNAVAIL. On 12/12/11 22:50, Christoph Egger wrote: > [...] > ada0: Previously was known as ad4 > [...] > Trying to mount from zfs:base/root [rw]... > vdev_geom_open_by_guid:352[1]: Searching by guid [$number] > vdev_geom_read_guid:239[1]: Reading guid from ada0 > vdev_geom_read_guid:273[1]: guid for ada0 is $number > vdev_geom_attach:95[1]: Attaching to ada0. > vdev_geom_attach:116[1]: Created geom consumer for ada0 > vdev_geom_open_by_guid:363[1]: Attach by guid [$number] succegged, provider > /dev/ada0 > vdev_geom_detach:156[1]: Closing access to ada0 > vdev_geom_detach:160Mounting from zfs:base/root failed with error 6 Destroyed > consumer to ada0 > > vdev_geom_detach:168[1]: Loader variables: > Destroyed geom zfs::vdev. vfs.root.mountfrom=zfs:base/root That looks like the same issue to me - ad4 became ada0 - but Christoph said that the zpool had been created from the installer. The installer usually uses a (msdos) partition as a ZFS physical volume? So perhaps it should have tried to attach /deve/ada0s[0-9] here, but mistakenly attached /dev/ada0 because it saw the disklabel (with correct guid) near the end of the disk? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/50e90305.6030...@pyro.eu.org
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
El 17 d’abril de 2012 22:07, Christoph Egger ha escrit: >> Confirmed: the list is empty. The device nodes aren't present. >> Furthermore, rebooting doesn't help but shutdown fixes the problem. >> >> Christoph, I only hit this problem in VirtualBox. Did you experience >> it with real hardware, also VM...? > > I am experiencing this on real hardware (Thinkpad X220) and I also for > clean boots (not rebooting). Perhaps it's not the same bug I'm experiencing. If you hit it again, try that "?" command and see if the device nodes are present. Also please take note of the error number. -- Robert Millan -- 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/caofdtxmwotwhttv9njeubv-8hnmqq9v-tzz0ombhp-_emor...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Robert Millan writes: > retitle 651624 sometimes device nodes disappear after a reboot, making > them inaccessible to root file system > thanks > > El 10 d’abril de 2012 17:38, Robert Millan ha escrit: >> Some tests that could confirm this, when any of us hits the problem again: >> >> - When you get the mount error, type "?" in mountroot prompt. It >> should give you a list of device nodes (e.g. ada0s2, ada0s1, ada0...). >> If it's empty, that's the reason it can't mount the ZFS root. > > Confirmed: the list is empty. The device nodes aren't present. > Furthermore, rebooting doesn't help but shutdown fixes the problem. > > Christoph, I only hit this problem in VirtualBox. Did you experience > it with real hardware, also VM...? I am experiencing this on real hardware (Thinkpad X220) and I also for clean boots (not rebooting). Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/873982yve9@hepworth.siccegge.de
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
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
retitle 651624 sometimes device nodes disappear after a reboot, making them inaccessible to root file system thanks El 10 d’abril de 2012 17:38, Robert Millan ha escrit: > Some tests that could confirm this, when any of us hits the problem again: > > - When you get the mount error, type "?" in mountroot prompt. It > should give you a list of device nodes (e.g. ada0s2, ada0s1, ada0...). > If it's empty, that's the reason it can't mount the ZFS root. Confirmed: the list is empty. The device nodes aren't present. Furthermore, rebooting doesn't help but shutdown fixes the problem. Christoph, I only hit this problem in VirtualBox. Did you experience it with real hardware, also VM...? -- Robert Millan -- 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/caofdtxojz4dbauvydsczygeoflunknx60jwpbvqgz+1rxt1...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi, I suspect this bug has nothing to do with the actual content of the device. Some hints: - It recently happened in one of my VMs. Tried rebooting a few times, always failed. Then instead of reboot I shut down and restart, then it works. Disk content has to be exactly the same in all tests, since nobody mounted it read-write. - In one of those reboots, I tried booting from a rescue disk (to try to fiddle a bit with the data using "zpool import"). Then I found that /dev nodes WERE NOT EVEN PRESENT. Again, rebooting didn't help, but after shut down and restart everything is back to normal. - Remember that "error 6" when the problem happens? 6 is ENXIO (Device not present). The picture begins to look like disks are not being detected. GRUB is not affected because it relies on the BIOS, and on VMs the BIOS is likely to bypass the standard ATA interface. Some tests that could confirm this, when any of us hits the problem again: - When you get the mount error, type "?" in mountroot prompt. It should give you a list of device nodes (e.g. ada0s2, ada0s1, ada0...). If it's empty, that's the reason it can't mount the ZFS root. - From GRUB prompt, try "insmod ata". Then "ls" should give you a list of disks, but this time using ATA rather than BIOS. Check if that list is empty. -- Robert Millan -- 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/CAOfDtXMe5wdPm2gx=r25nhmtuobvagwfqa4+5ooholjeg4g...@mail.gmail.com
Re: Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
El 25 de març de 2012 23:07, Christoph Egger ha escrit: > Robert Millan writes: >> I'm not sure if people in debian-bsd can help with this. I myself >> can't. Maybe you should try to reproduce this in a pure FreeBSD >> environment by trying to import the pool from a FreeBSD system. If it >> can be imported with kFreeBSD 8.x (either GNU or BSD userland), but >> not with pure FreeBSD 9.0, then it's IMHO worth reporting to ZFS >> experts in freebsd-fs. > > I was now able to reproduce the problem in a 10-CURRENT build done on > pure freebsd 9.0-STABLE with default cc though the failing box is (of > course) still kfreebsd. I was hit by this too. Really annoying :-( > There should be no othyer debian influcenes before the reoot filesystem > comes available apart from grub right? Going to take this upstream if > so. There might be something written on disk by Debian kernel that upstream kernel doesn't. Probably not file system corruption since it's clearly recoverable (as I write, my system just came back to normal after simply booting a D-I image and importing the pool there). But as the data is there, if upstream kernels can't access it I think it's probably relevant to them. If you bring this upstream, I recommend writing to freebsd-fs, it's much easier to get attention there than by filing a PR. -- Robert Millan -- 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/caofdtxno2ovtg4i+1yavs0nnctspu3ehl+gwvccwfc3lmyr...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi! Robert Millan writes: > I'm not sure if people in debian-bsd can help with this. I myself > can't. Maybe you should try to reproduce this in a pure FreeBSD > environment by trying to import the pool from a FreeBSD system. If it > can be imported with kFreeBSD 8.x (either GNU or BSD userland), but > not with pure FreeBSD 9.0, then it's IMHO worth reporting to ZFS > experts in freebsd-fs. I was now able to reproduce the problem in a 10-CURRENT build done on pure freebsd 9.0-STABLE with default cc though the failing box is (of course) still kfreebsd. There should be no othyer debian influcenes before the reoot filesystem comes available apart from grub right? Going to take this upstream if so. Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/87limoe6ew@hepworth.siccegge.de
Re: Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
El 8 de febrer de 2012 19:16, Christoph Egger ha escrit: > pool: base > id: 6831564585978878790 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > The pool may be active on another system, but can be imported using > the '-f' flag. > see: http://www.sun.com/msg/ZFS-8000-5E > config: > > base FAULTED corrupted data > 12903006650529041588 UNAVAIL corrupted data > > > This remindes a bit on what happends without the zpool.cache I'm not sure if people in debian-bsd can help with this. I myself can't. Maybe you should try to reproduce this in a pure FreeBSD environment by trying to import the pool from a FreeBSD system. If it can be imported with kFreeBSD 8.x (either GNU or BSD userland), but not with pure FreeBSD 9.0, then it's IMHO worth reporting to ZFS experts in freebsd-fs. -- Robert Millan -- 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/caofdtxowr_ohcgdbov2093t0wg7yedavek-fqw_jqouq22_...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi! Just an interesting Gem I noticed. `zpool list -o version` tells me my pool is at version 28 while `zdb` thinks it's version 15. Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/87lioa9x8n@hepworth.siccegge.de
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi! Robert Millan writes: > El 21 de desembre de 2011 12:23, Christoph Egger > ha escrit: >> I've managed to build kfreebsd-9 9.0~svn228246-2 now and using that >> kernel (cp to /boot) mounts the zfs root while both the stable and the >> unstable 9.0 kernel do not. Not sure why. > > Sounds like heisenbug. Could you try the other test? (boot from > rescue image and attempt zpool import) pool: base id: 6831564585978878790 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://www.sun.com/msg/ZFS-8000-5E config: baseFAULTED corrupted data 12903006650529041588 UNAVAIL corrupted data This remindes a bit on what happends without the zpool.cache Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/8739alm8zi@hepworth.siccegge.de
Re: Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
El 21 de desembre de 2011 12:23, Christoph Egger ha escrit: > I've managed to build kfreebsd-9 9.0~svn228246-2 now and using that > kernel (cp to /boot) mounts the zfs root while both the stable and the > unstable 9.0 kernel do not. Not sure why. Sounds like heisenbug. Could you try the other test? (boot from rescue image and attempt zpool import) -- Robert Millan -- 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/caofdtxmpotydjudkemffgo2gvotgdwup1anjakyszv2z4vs...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
On Tue, Dec 13, 2011 at 08:06:42AM +0100, Robert Millan wrote: > 2011/12/12 Christoph Egger : > >> Please try setting vfs.zfs.debug=1 from GRUB and see if relevant > >> output turns up. > > > > [...] > > Can't see anything relevant in those messages. Could you rebuild > kfreebsd-9 with debug options (see attachment) and try that? The > internal sanity checks might bring up something useful. I've managed to build kfreebsd-9 9.0~svn228246-2 now and using that kernel (cp to /boot) mounts the zfs root while both the stable and the unstable 9.0 kernel do not. Not sure why. Regards Christoph -- 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/20111221112301.ga15...@oteiza.siccegge.de
Bug#652469: Fwd: Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
El 17 de desembre de 2011 21:23, Edward Tomasz Napierała ha escrit: > Wiadomość napisana przez Arno Töll w dniu 17 gru 2011, o godz. 16:12: >>> Maybe we should discuss this with FreeBSD? We could even propose them >>> to make SMP the default there. > > SMP has been enabled in the the default FreeBSD kernel (GENERIC) > for quite some time now. Oh, sorry, I've been looking at the patched file in Debian (we remove it from GENERIC and add it back via debian/arch/). Thanks for correcting me. In that case, how about: - Add SMP for all flavours - Replace -smp flavour with -pae flavour ? -- Robert Millan -- 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/caofdtxokf_yszzjqegrlywchuwqcj6vus76hshke-cqre0r...@mail.gmail.com
Bug#652469: Fwd: Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
Wiadomość napisana przez Arno Töll w dniu 17 gru 2011, o godz. 16:12: >> Maybe we should discuss this with FreeBSD? We could even propose them >> to make SMP the default there. SMP has been enabled in the the default FreeBSD kernel (GENERIC) for quite some time now. -- If you cut off my head, what would I say? Me and my head, or me and my body? -- 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/84d9a0cf-6981-4244-a881-566cb2a11...@freebsd.org
Bug#652469: Fwd: Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Forward to 652...@bugs.debian.org I forgot, sorry. - Original Message On 17.12.2011 15:49, Robert Millan wrote: > I'm not sure how relevant is > this factor but it is unexistant on GNU/kFreeBSD, so I think this > should be accounted for when taking Linux as reference. More or less unexisting. The very same candidates that would cause one to remain on a IA32 user land because of non-free cruft on Linux mostly also holds FreeBSD as it is typically the very same software people want to run through the Linux emulation layer. Think of Flash and Google Earth for example. That said I have no use for kfreebsd on a desktop and I hence didn't try any of those programs under kfreebsd so far. > Another likely difference is that kFreeBSD in PAE mode has major > drawbacks (in particular we'd have to disable a bunch of drivers, see > sys/i386/conf/PAE and URL I pasted before). All in all, I have the > impression that using PAE would be unacceptable for the majority of > i686 users. That on the other hand is a good rationale not to use PAE. However, if you read the discussion I noted there is no significant performance improvement [on Linux] to use i686 over i486. Thus, users of 686 capable CPUs may happily use the 486 branch, whereas people who need PAE need 686 anyway. > Good question. TBH I really dislike adding new flavours for PAE > unless SMP is merged. Then we'd only have to replace 686-smp with > 686-pae instead of adding two new flavours. We're not freezing tomorrow, maybe consider waiting for upstream regarding SMP support upstream. > I don't know if SMP option is really usable on uniprocessor hardware. > FWIW, I've tested -smp flavours for 8.3 and 9.0 on an uniprocessor VM > and both seem to work fine. I would hope it is usable. If it weren't that would certainly be a bug in the SMP code. However, there might be design decisions that make SMP slower on uniprocessor hardware (or not - I don't know as said). > Maybe we should discuss this with FreeBSD? We could even propose them > to make SMP the default there. That makes sense, yes. In particular I guess we shouldn't be inventing use cases which aren't supported in such a configuration upstream either. > Given that a PAE kernel has important drawbacks (like disabling a lot > of drivers), I'd rather leave it to the user to explicitly install > those kernels after a normal kFreeBSD is running. I wrote that under the impression that such a kernel would crash on systems with more than 4G RAM. That would leave people without possibility to install kfreebsd. If that's sorted out, i.e. the bug has been fixed I am for a non PAE kernel too. I do not think there would be any benefit to use >= 4G RAM in the context of D-I. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO7LFbAAoJEMcrUe6dgPNtMjQP/ArffA1pH++cbXkYrYKtDuWr gSE/lPpPE8039iEfMIwlma3GE47YxYSf41L57dSfThnZ2nBtTMbt7QDuG+g1dEca s9a5tuIf0QmruwNeiOkhFmxnowPbwmfrORGLS69caJYjc85pjfVQJD56NnB50pcO j8fkr4DyqvG8wqzzSmkkOutaSHkwUm3UbZaemchA2OYlaP20NbhVzkGj9Ze36Nnx 2mYSj8F2XvwzlYwhUqT9puJlSfWCgeWYXQmoGw1+yo8rudkEN7aApUsrADUc4wi6 jP5TxykGtVoZm0Nd0q/+gPhBoddevQZs0afaXGUpltdGxXdw0SjdNWuQfLbqdxtF q6CwTiSEevIirf7+Tqaqo60GVScWr6fwGMw5SnU98FC9lElDUJokN2/DWzeTfBW0 duwyC7lGqOlKeIzCbRYj/KOJDOEh7uT5kBXcD/Em18hBzC86ypjQZeYDOTrhJ+Jp FNkjoQ+iGC9l1hC/sUWkEsSgX0MDFMGv8RAJ4kp42MAZZb4zl+6keDsU4L3/pgBA Zc1Vlm9YmxkjAwqDD4NZWsUGsL8T2AgiZXO9oYU3Whgk2jfhStqq/d5hBmwOzbvy hgx4dtGpdgsmfaaMts+uw66D0cHh6cag0w6WE0QgnXUhayW/yAVSZJpU7dS0NVIS 4gdTDnXPmAmF9TH+qWDr =E/Ed -END PGP SIGNATURE- -- 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/4eecb15b.7070...@toell.net
Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17.12.2011 15:49, Robert Millan wrote: > I'm not sure how relevant is > this factor but it is unexistant on GNU/kFreeBSD, so I think this > should be accounted for when taking Linux as reference. More or less unexisting. The very same candidates that would cause one to remain on a IA32 user land because of non-free cruft on Linux mostly also holds FreeBSD as it is typically the very same software people want to run through the Linux emulation layer. Think of Flash and Google Earth for example. That said I have no use for kfreebsd on a desktop and I hence didn't try any of those programs under kfreebsd so far. > Another likely difference is that kFreeBSD in PAE mode has major > drawbacks (in particular we'd have to disable a bunch of drivers, see > sys/i386/conf/PAE and URL I pasted before). All in all, I have the > impression that using PAE would be unacceptable for the majority of > i686 users. That on the other hand is a good rationale not to use PAE. However, if you read the discussion I noted there is no significant performance improvement [on Linux] to use i686 over i486. Thus, users of 686 capable CPUs may happily use the 486 branch, whereas people who need PAE need 686 anyway. > Good question. TBH I really dislike adding new flavours for PAE > unless SMP is merged. Then we'd only have to replace 686-smp with > 686-pae instead of adding two new flavours. We're not freezing tomorrow, maybe consider waiting for upstream regarding SMP support upstream. > I don't know if SMP option is really usable on uniprocessor hardware. > FWIW, I've tested -smp flavours for 8.3 and 9.0 on an uniprocessor VM > and both seem to work fine. I would hope it is usable. If it weren't that would certainly be a bug in the SMP code. However, there might be design decisions that make SMP slower on uniprocessor hardware (or not - I don't know as said). > Maybe we should discuss this with FreeBSD? We could even propose them > to make SMP the default there. That makes sense, yes. In particular I guess we shouldn't be inventing use cases which aren't supported in such a configuration upstream either. > Given that a PAE kernel has important drawbacks (like disabling a lot > of drivers), I'd rather leave it to the user to explicitly install > those kernels after a normal kFreeBSD is running. I wrote that under the impression that such a kernel would crash on systems with more than 4G RAM. That would leave people without possibility to install kfreebsd. If that's sorted out, i.e. the bug has been fixed I am for a non PAE kernel too. I do not think there would be any benefit to use >= 4G RAM in the context of D-I. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO7LCsAAoJEMcrUe6dgPNtTSwQAKHBVtEWDs+KbjmkHjMRtRSQ YOW2wtqU2sStexJv39oKYs7TlW9A7os6Qg30fKWBQGa17j6xHFSmn8/TqK1dqKfQ EW2xSe7my7Oa9oleuLZoCkIzodvloKXhtDZEvDGx/br/SM3busw2wSg0Md1MDS0r FthJlc76BhZujMscSLGISeSluRX6qJlBkDKZWY9DeMQbg91f6CLPwVQoPVraDCOd lxRyDCh/RzVxR7Z6yUybEImFJqQw3kPBYKyMV6SxLdLa8C1xMc7B9nRtA2vfJXew 5A7FvPzcQgRaqhg6k0LJ/cSj7eGsCVMddGhWZ1+DS691DEkVgvm7nFWRGx2t4c1P S06X2E7/oP0XBp+h02yw7vLGOxoBweULyLmMlEbs39f4FoMMlUYUzECiHn+7rfXO po0HgT2B2zpzSs5bIIWmVUjjBnmESvWD34H1NTyJDXYAL1X0YhaGW0/6ox5J4SP5 VAMrXOARcSHjLw34he1I6Dj4/kwOCJmEBm/BdWMfNL2VASGJCJ/Cj3m7Mvqb+V3L 1KLEXfHIMPYLZu9NPkm4rrtm9JKgqCX9BA33umqXR8tbemRXvygw/mv45txk2mx1 o4brqOUfs2v0TYziVT7g0tO6ErHQwyA7BiJEyvoxbstpfZfZPEQkXfZ+BKd9KqzJ F2F2491RocLNI4PNuyxh =2Cdd -END PGP SIGNATURE- -- 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/4eecb0ac.1060...@toell.net
Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
El 17 de desembre de 2011 13:51, Arno Töll ha escrit: > On 17.12.2011 12:09, Robert Millan wrote: >> - Add additional flavours (which ones? 686, 686-smp ... ? and then >> which ones to provide with D-I?) > > That's what we're doing on Linux and that seems the best compromise. I think on GNU/Linux many people want to use IA32 version even with CPUs that support AMD mode, because they want IA32 userland for binary compatibility with non-free software. I'm not sure how relevant is this factor but it is unexistant on GNU/kFreeBSD, so I think this should be accounted for when taking Linux as reference. Another likely difference is that kFreeBSD in PAE mode has major drawbacks (in particular we'd have to disable a bunch of drivers, see sys/i386/conf/PAE and URL I pasted before). All in all, I have the impression that using PAE would be unacceptable for the majority of i686 users. > On Linux there are many different kernel flavors where it is being worked > on to reduce their amount. I propose -486 for older PCs and 686-pae for > newer PCs. See [1] on more discussion about the minimal required processor. > > I am not sure if FreeBSD has drawbacks to use a SMP flavored kernel on a > traditional legacy system with one CPU only. If yes there perhaps should > be a -smp version for each too. Good question. TBH I really dislike adding new flavours for PAE unless SMP is merged. Then we'd only have to replace 686-smp with 686-pae instead of adding two new flavours. I don't know if SMP option is really usable on uniprocessor hardware. FWIW, I've tested -smp flavours for 8.3 and 9.0 on an uniprocessor VM and both seem to work fine. Maybe we should discuss this with FreeBSD? We could even propose them to make SMP the default there. > Regarding D-I I guess there is no easy way to tell in > advance whether the system needs a PAE kernel or not, Given that a PAE kernel has important drawbacks (like disabling a lot of drivers), I'd rather leave it to the user to explicitly install those kernels after a normal kFreeBSD is running. -- Robert Millan -- 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/caofdtxnatjqwkpwafzzmue5c_vyropdofdp1eyzwywca6mf...@mail.gmail.com
Processed: Re: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
Processing commands for cont...@bugs.debian.org: > clone 652448 -1 Bug#652448: panic when booting on a machine with >= 4 GiB of RAM Bug 652448 cloned as bug 652469. > severity -1 wishlist Bug #652469 [kfreebsd-image-9.0-0-686] panic when booting on a machine with >= 4 GiB of RAM Severity set to 'wishlist' from 'important' > retitle -1 PAE support Bug #652469 [kfreebsd-image-9.0-0-686] panic when booting on a machine with >= 4 GiB of RAM Changed Bug title to 'PAE support' from 'panic when booting on a machine with >= 4 GiB of RAM' > thanks Stopping processing here. Please contact me if you need assistance. -- 652469: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652469 652448: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652448 -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 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.13241309439248.transcr...@bugs.debian.org
Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
clone 652448 -1 severity -1 wishlist retitle -1 PAE support thanks Hi Arno, I'm sorry, this is my fault but when I read your reply I notice I actually lumped together two different issues: #1- An important usability bug: kernel panics instead of just discarding unusable RAM. #2- Lack of PAE feature which would allow using all the available RAM instead of discarding some. I'm cloning this bug so we can have separate discussion about the benefits of enabling PAE without cluttering the panic bug with irrelevant information. -- Robert Millan -- 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/caofdtxmwgo_iuv+uwt7crdqf0cgmerqm9hre6tflbhebg47...@mail.gmail.com
Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
El 17 de desembre de 2011 12:09, Robert Millan ha escrit: > kfreebsd-image-9.0-0-686 (and most likely all IA32 flavours that don't use > PAE) > panics when booting on a machine with 4 GiB of RAM (or more). It seems that this problem only happens when mfsroot is being used. Otherwise the extra RAM is safely discarded. Also, it is reproducible on FreeBSD as well, so I've forwarded it to upstream (http://www.freebsd.org/cgi/query-pr.cgi?pr=163410) -- Robert Millan -- 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/CAOfDtXOJ+wD0K8=rbjmjhmo8uwgxf0siquv0ojgy-jxhbg6...@mail.gmail.com
Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 17.12.2011 12:09, Robert Millan wrote: > - Add additional flavours (which ones? 686, 686-smp ... ? and then > which ones to provide with D-I?) That's what we're doing on Linux and that seems the best compromise. On Linux there are many different kernel flavors where it is being worked on to reduce their amount. I propose -486 for older PCs and 686-pae for newer PCs. See [1] on more discussion about the minimal required processor. I am not sure if FreeBSD has drawbacks to use a SMP flavored kernel on a traditional legacy system with one CPU only. If yes there perhaps should be a -smp version for each too. Generally it seems an upstream bug to me though if the kernel crashes on such a system. Regarding D-I I guess there is no easy way to tell in advance whether the system needs a PAE kernel or not, and the fact the wrong choice crashes does not make it any more easy to choose a kernel. > - Fail gracefuly and prompt user to either remove RAM or use AMD64 > version Is it really safe to assume every system with more than 4G RAM supports the long mode for sure? [1] <1321742531.2885.227.camel@deadeye> - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO7JBuAAoJEMcrUe6dgPNtI5wQALIVcImtSc40RWWa397EIP1E C2rqUq/HvSyYLb1R4nOj4y4oo5FQKPKiqQJPl21VuKid9I+jv1Zpn0kdc2UlWdTt ldHOBu16IMv+bluP4ta6UDWLcBU+h44JpRo0j1IfvPBKttvP5mvFvZwRp2Yooxnu 557PQx5lytmPrOh12Xmem2Ax/BhzPSX/eNyYXh3pL11lJHP8GF6/qyeDothvR58A 8HL7lyj17YkuFWe+1yIkPY78iTedtXQcXzDCcqa6d7z6sKfKuwIqqv1HeIxWeMRO S4ve348KWuymmRTVOc3tlStiKSnbMpa+sRaQZfa/xRT6dyg/IL0GDiasR+u1JTya flsA7QqVhIlw/l8JuBid3LmfrUdw+DNSqUP9BajoKAwHR2weYwblkaOZlONEXv18 eWRAyxncMoyXzCVuuoDRZWFYI+H/d/ST1BRwf/mra7VUgoAfaZFacYVaZOdd0HnT pDx+BPSvvcjAJIukO5D+NtpiuZzb8j3MyT/lflnRmFmL4T/W4LL+DkzFNqs9eDus gxutKg4qbM67IIH5Q5oA+SKcmAibFw7qLl18ll4yqcT2hpMN2ipKYKIYdqVMtcsq uaL8zi8uHRg2f07Y71gIjbpg0urqBPbC9u2myFspQD2VGOQEITnIQ7lAtkh+q7H7 mr6RjpGKLmpPgWo9Nzwp =4/CO -END PGP SIGNATURE- -- 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/4eec906e.2010...@toell.net
Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
Package: kfreebsd-image-9.0-0-686 Version: 9.0~svn228246-1 Severity: important kfreebsd-image-9.0-0-686 (and most likely all IA32 flavours that don't use PAE) panics when booting on a machine with 4 GiB of RAM (or more). Possible ways out of this: - Enable PAE for all flavours. There are major drawbacks, see: http://www.freebsd.org/doc/handbook/kernelconfig-config.html - Add additional flavours (which ones? 686, 686-smp ... ? and then which ones to provide with D-I?) - Fail gracefuly and prompt user to either remove RAM or use AMD64 version Please comment! -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kfreebsd-image-9.0-0-686 depends on: ii freebsd-utils 8.1-5 FreeBSD utilities needed for GNU/k ii kldutils 8.1-5 tools for managing kFreeBSD module Versions of packages kfreebsd-image-9.0-0-686 recommends: pn libc0.1-i686 (no description available) kfreebsd-image-9.0-0-686 suggests no packages. -- 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/20111217110947.93459.52856.reportbug@thorin
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Another test that might be useful is booting from a kfreebsd-9 rescue image and trying to import your pool from command-line (zpool import -o altroot=/target base). If that fails it'll probably give more useful diagnostics. -- Robert Millan -- 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/CAOfDtXOHU+ns2LSHHdJM9=ejgq2-eksnb3ww3vgujajcfdo...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
2011/12/12 Christoph Egger : >> Please try setting vfs.zfs.debug=1 from GRUB and see if relevant >> output turns up. > > [...] Can't see anything relevant in those messages. Could you rebuild kfreebsd-9 with debug options (see attachment) and try that? The internal sanity checks might bring up something useful. -- Robert Millan --- kfreebsd-9/sys/amd64/conf/GENERIC 2011-12-10 21:56:22.876720247 +0100 +++ kfreebsd-10/sys/amd64/conf/GENERIC 2011-12-10 21:36:24.844192564 +0100 @@ -71,8 +71,20 @@ #options KDTRACE_FRAME # Ensure frames are compiled in #options KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel -options KDB # Kernel debugger related code -options KDB_TRACE # Print a stack trace for a panic + +# Debugging support. Always need this: +options KDB # Enable kernel debugger support. +# For minimum debugger support (stable branch) use: +#options KDB_TRACE # Print a stack trace for a panic. +# For full debugger support use this instead: +options DDB # Support DDB. +options GDB # Support remote GDB. +options DEADLKRES # Enable the deadlock resolver +options INVARIANTS # Enable calls of extra sanity checking +options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS +options WITNESS # Enable checks to detect deadlocks and cycles +options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed +options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # Make an SMP-capable kernel by default #options SMP # Symmetric MultiProcessor Kernel
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Robert Millan writes: > 2011/12/12 Christoph Egger : >>> Maybe they've fixed this bug recently. I just uploaded a new SVN >>> snapshot to experimental (9.0~svn228246-1), can you try? >> >> Still the same failure. > > Please try setting vfs.zfs.debug=1 from GRUB and see if relevant > output turns up. [...] ada0: Previously was known as ad4 [...] Trying to mount from zfs:base/root [rw]... vdev_geom_open_by_guid:352[1]: Searching by guid [$number] vdev_geom_read_guid:239[1]: Reading guid from ada0 vdev_geom_read_guid:273[1]: guid for ada0 is $number vdev_geom_attach:95[1]: Attaching to ada0. vdev_geom_attach:116[1]: Created geom consumer for ada0 vdev_geom_open_by_guid:363[1]: Attach by guid [$number] succegged, provider /dev/ada0 vdev_geom_detach:156[1]: Closing access to ada0 vdev_geom_detach:160Mounting from zfs:base/root failed with error 6 Destroyed consumer to ada0 vdev_geom_detach:168[1]: Loader variables: Destroyed geom zfs::vdev. vfs.root.mountfrom=zfs:base/root Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/87sjkpz9oa@hepworth.siccegge.de
Re: Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
2011/12/12 Christoph Egger : >> Maybe they've fixed this bug recently. I just uploaded a new SVN >> snapshot to experimental (9.0~svn228246-1), can you try? > > Still the same failure. Please try setting vfs.zfs.debug=1 from GRUB and see if relevant output turns up. -- Robert Millan -- 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/CAOfDtXOM3rChO+qE0gq1gWuGkVJi6d6ms_0LsLM=vsw+5rv...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi! On Sun, Dec 11, 2011 at 12:57:45PM +0100, Robert Millan wrote: > 2011/12/10 Christoph Egger : > > The official 9.0 kernel manages to mount the root fs > > Maybe they've fixed this bug recently. I just uploaded a new SVN > snapshot to experimental (9.0~svn228246-1), can you try? Still the same failure. Regards Christoph -- 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/20111212122759.ga30...@oteiza.siccegge.de
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
2011/12/11 Steven Chamberlain : > * I managed to install to a new ZFS root under kfreebsd 8.2, upgrade to > kfreebsd 9 and still boot it; so what did we do differently for > Christoph to have this issue? Hard to say. It's probably just not reproducible every time, or depends on factors that can't be easily controlled. IMHO our best bet right now is try latest 9.0 snapshot, and if that's still broken then try setting vfs.zfs.debug=1 and watch the output. > * how did Christoph create his zpool and ZFS root filesystem? because > for me this seemed broken in recent d-i daily images, due to the wrong > zfsutils being included; Yes. It's badly broken right now (for many different reasons), I'm surprised he could finish the install too. However kernels should operate on best-effort basis. If there's enough information for other kfreebsd versions to boot, there should be for 9.0 too. -- Robert Millan -- 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/CAOfDtXOpAfN3VjQKSU5titsF5rbpCLH273jj4a52SJ0OhgZ1=w...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi, On 11/12/11 12:03, Robert Millan wrote: > Please don't add unrelated information to bug reports. If you found a > new bug, you can file it, or we can discuss it in the mailing list(s). Okay sorry, some of that I ought to file separate bugs for, but regarding this bug I was really trying to say: * I managed to install to a new ZFS root under kfreebsd 8.2, upgrade to kfreebsd 9 and still boot it; so what did we do differently for Christoph to have this issue? * how did Christoph create his zpool and ZFS root filesystem? because for me this seemed broken in recent d-i daily images, due to the wrong zfsutils being included; * I'm curious, did Christoph actually boot with kfreebsd 8.2 before installing kfreebsd 9? or did he install kfreebsd 9 sometime during the install and try to boot with that kernel first? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4ee4bd41.60...@pyro.eu.org
Re: Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi Steven, Please don't add unrelated information to bug reports. If you found a new bug, you can file it, or we can discuss it in the mailing list(s). I replaced the CC to BTS with debian-bsd. 2011/12/11 Steven Chamberlain : > which only has kfreebsd-image-8.2-1-amd64 8.2-15 (I guess because > kfreebsd-9 isn't in testing quite yet?). That might be, yes. Is kfreebsd-9 available in boot menu? > I had difficulty getting past the partitioner stage of the install. I > could create/see the ZFS pool from the partitioner's submenu, but it > would not ask me to set a mount point. The main partitioner screen > would not list the ZFS pool/filesystems, only the physical drive and > partition that I'd added to the pool (correctly marked as 'in use'). > > Then I noticed the debian installer seemed to be using zfsutils-udeb > 8.3~svn226546-6 from sid, which according to #648744 probably doesn't > work with 8.2. So, I downgraded to zfsutils-udeb 8.2-4 inside of the > running installer ramdisk (from the console, using wget, ar and tar to > overwrite zpool/zfs and libs), and was then able to delete/recreate a > ZFS pool and root fs that worked and allowed me to finish installing. Current zfsutils only works with kfreebsd 9.0 or 8.3 snapshots. I added an isinstallable script in zfsutils-udeb to prevent it from being installed on 8.2, but apparently it's not working. I don't know why. Perhaps you can find out what's wrong? -- Robert Millan -- 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/CAOfDtXP=y25W5oRq+B70G74DAa1DVeM=gWfzUmNu0Jtw18G9=q...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
2011/12/10 Christoph Egger : > The official 9.0 kernel manages to mount the root fs Maybe they've fixed this bug recently. I just uploaded a new SVN snapshot to experimental (9.0~svn228246-1), can you try? -- Robert Millan -- 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/CAOfDtXPATg=qh1c+tfprgd1jrxsbsbttabs5yr-kq8zr2fu...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
On 10/12/11 16:52, Christoph Egger wrote: > Booting from a zfs root filesystem (created with the daily installer > and a 8.2 kernel) fails with the kfreebsd 9 kernel Hi, I just had a go at this myself and it worked. I had trouble with zfsutils during install though which may be relevant. I used this daily netinst image: http://cdimage.debian.org/cdimage/daily-builds/daily/20111210-7/kfreebsd-amd64/jigdo-cd/debian-testing-kfreebsd-amd64-netinst.jigdo which only has kfreebsd-image-8.2-1-amd64 8.2-15 (I guess because kfreebsd-9 isn't in testing quite yet?). I may have had to go to GRUB command line and 'set mfsroot_path=/boot/mfsroot.gz' to boot the installer. I had difficulty getting past the partitioner stage of the install. I could create/see the ZFS pool from the partitioner's submenu, but it would not ask me to set a mount point. The main partitioner screen would not list the ZFS pool/filesystems, only the physical drive and partition that I'd added to the pool (correctly marked as 'in use'). Then I noticed the debian installer seemed to be using zfsutils-udeb 8.3~svn226546-6 from sid, which according to #648744 probably doesn't work with 8.2. So, I downgraded to zfsutils-udeb 8.2-4 inside of the running installer ramdisk (from the console, using wget, ar and tar to overwrite zpool/zfs and libs), and was then able to delete/recreate a ZFS pool and root fs that worked and allowed me to finish installing. On first boot with 8.2 kernel, I enabled the sid APT repo, installed latest kfreebsd-image-9 (requiring newer zfsutils) and rebooted back into the ZFS root fs with that kernel just fine. zpool status showed the pool as online/healthy, but suggested I upgrade to version 28, which was successful also. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4ee458e9.4050...@pyro.eu.org
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
2011/12/10 Christoph Egger : > Setting up kfreebsd-downloader (9.0~rc2-1) ... > --2011-12-10 18:40:14-- > http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.0-RC2/kernel.txz > Resolving ftp.freebsd.org (ftp.freebsd.org)... 2001:6c8:2:600::132, > 2001:4f8:0:2::e, 149.20.64.73, ... > Connecting to ftp.freebsd.org (ftp.freebsd.org)|2001:6c8:2:600::132|:80... > connected. > HTTP request sent, awaiting response... 404 Not Found > 2011-12-10 18:40:14 ERROR 404: Not Found. I just uploaded 9.0-RC3. -- Robert Millan -- 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/caofdtxp1r2kbhjh5cjcpo7aydfjogmvydukw-sssrz6ionx...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi! Christoph Egger writes: > Robert Millan writes: >> Can you reproduce this with upstream kernel? (kfreebsd-downloader). >> If it's an upstream bug, it'd help to get upstream involved IMHO. > > trying to use a bootonly iso via netvoot also failed. will continue > trying stuff. The official 9.0 kernel manages to mount the root fs Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/87borg2oyp@hepworth.siccegge.de
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Hi! Robert Millan writes: > Can you reproduce this with upstream kernel? (kfreebsd-downloader). > If it's an upstream bug, it'd help to get upstream involved IMHO. Unfortunately the downloader doesn't work any more as rc3 is released: Setting up kfreebsd-downloader (9.0~rc2-1) ... --2011-12-10 18:40:14-- http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.0-RC2/kernel.txz Resolving ftp.freebsd.org (ftp.freebsd.org)... 2001:6c8:2:600::132, 2001:4f8:0:2::e, 149.20.64.73, ... Connecting to ftp.freebsd.org (ftp.freebsd.org)|2001:6c8:2:600::132|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-12-10 18:40:14 ERROR 404: Not Found. dpkg: error processing kfreebsd-downloader (--configure): subprocess installed post-installation script returned error exit status 8 Errors were encountered while processing: kfreebsd-downloader trying to use a bootonly iso via netvoot also failed. will continue trying stuff. Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/87zkf0491g@hepworth.siccegge.de
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
2011/12/10 Christoph Egger : > Booting from a zfs root filesystem (created with the daily installer > and a 8.2 kernel) fails with the kfreebsd 9 kernel: kfreebsd can mount > a root filesystem and the kernel drops in the manual root filesystem > selection dialog. This happens both, with the 8.2 style "old" zpool > format as well as the "new" zpool format 28. In contrast > experimental's -10 and 8.3 kernel both boot fine here. > > From within the netboot-9 installer the zfs pool is always marked as > damaged while the -8 based one thinks it is fine btw. Can you reproduce this with upstream kernel? (kfreebsd-downloader). If it's an upstream bug, it'd help to get upstream involved IMHO. -- Robert Millan -- 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/CAOfDtXO=j62j0vuohj7+j6uwueymcx5opyeo9vlydouqque...@mail.gmail.com
Bug#651624: Booting from zfs root seems to not work 8.3 and 10.0 however work
Package: kfreebsd-image-9-amd64 Version: 9.0~svn227451-6 Severity: important Hi! Booting from a zfs root filesystem (created with the daily installer and a 8.2 kernel) fails with the kfreebsd 9 kernel: kfreebsd can mount a root filesystem and the kernel drops in the manual root filesystem selection dialog. This happens both, with the 8.2 style "old" zpool format as well as the "new" zpool format 28. In contrast experimental's -10 and 8.3 kernel both boot fine here. From within the netboot-9 installer the zfs pool is always marked as damaged while the -8 based one thinks it is fine btw. Regards Christoph -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.3-0-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages kfreebsd-image-9-amd64 depends on: ii kfreebsd-image-9.0-0-amd64 9.0~svn227451-6 kfreebsd-image-9-amd64 recommends no packages. kfreebsd-image-9-amd64 suggests no packages. -- no debconf information -- 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/20111210165258.2773.95763.report...@mitoraj.siccegge.de
Re: [PATCH] d-i manual: Preparing Files for USB Memory Stick Booting
Holger Wansing, le Mon 04 Oct 2010 21:55:17 +0200, a écrit : > And: at the beginning of that file (../en/install-methods/boot-usb-files.xml) > I read several times about Linux, even in the kfreebsd manual. > Could you check, if this is correct? It is not, I've already asked BSD people to check what should be kept for kFreeBSD and what shouldn't. Samuel -- 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/20101005211023.gl4...@const.famille.thibault.fr
Re: [PATCH] d-i manual: Preparing Files for USB Memory Stick Booting
Hello, Holger Wansing, le Mon 04 Oct 2010 21:55:17 +0200, a écrit : > (Samuel: maybe there is something not 100% correct with the arch options > for the kfreebsd manuals? Yes, see "TODO: update" in build/arch-options/kfreebsd-*. All these need to get fixed by people who actually know what kFreeBSD supports. > Now, kfreebsd-i386 is 'bootable-usb', but does not belong to 'x86' or > 'powerpc'.) Yes, because syslinux wouldn't be used in the kFreeBSD case. There'd need to be another phrase for kFreeBSD I guess, as I said in a mail some time ago, kFreeBSD people need to give a closer look at such parts of the manual. > -as well as syslinux and its > -configuration file. I've fixed the period, thanks. Samuel -- 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/20101004231744.gk5...@const.famille.thibault.fr
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
Booting broken with debian-installer
Hi there, 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. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org 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=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
booting on the serial console
Hi! I have successfully installed kFreeBSD on my workstation using QEMU, and I am now heading for my personnal holy grail: setting up a Soekris-based Debian GNU/kFreeBSD router. (For those who do not know those devices, soekris boxes are small embedded computers that have no display but a serial console.) So I need kFreeBSD to boot on the serial console port. I've been able to configure GRUB2 to use the serial console, but I can't figure out how to pass flags to the kernel so it uses the serial console too. 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 2. i need to specify the speed of the port. this is usually done in config options or at compile time. I tried setting hint.sio.0.flags="0x30" along with the other environment in grub, without any luck. What currently happens is that the serial port seems to freeze when the kernel is loaded. Any of you familiar with the boot process? Is there any way I can just revert back to the regular /boot/loader quickly? More generally: how do you pass boot time options like -s (since user mode) to the kernel? Thanks, A. Some references: * http://www.freebsd.org/doc/handbook/serialconsole-setup.html * http://soekris.com/net5501.htm * http://www.freebsd.org/cgi/man.cgi?query=boot&sektion=8 -- Antoine Beaupré Réseau Koumbit Networks +1.514.387.6262 signature.asc Description: Digital signature
problems booting GING 0.1.0 / bug report
Using default boot and other options I receive: acd0:Failure-Read_Big Hardware error asc=0x3e ascq=0x02 error=0 vm_fault:pager read error,pid338(sh) The only way I've gotten it to boot to desktop is in safe mode. When it does boot though, the display scrambles. I'm running two monitors in single monitor mode: the primary is unreadable and the secondary is barely readable (very distorted, compressed to the middle third of the display). I've used the readable one to try and change the settings>peripherials>display to fix the problem. Changing screen resolution just makes it worse and there is only one refresh rate setting of 73Hz. My monitors normally run 61Hz just fine. My machine is: MSI K8N Neo4 motherboard with built in ethernet ASUS AX3000SE/TD dual VGA video card (ATI) AMD64 3000+ CPU not OC'd 1Gig RAM Any suggestions? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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/
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? -- Matthew Garrett | [EMAIL PROTECTED]
