2005-10-17 18:01:04 +04:00
|
|
|
/*
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
* Copyright 2007, Ingo Weinhold, bonefish@cs.tu-berlin.de.
|
2007-07-16 03:51:21 +04:00
|
|
|
* Copyright 2002-2007, Axel Dörfler, axeld@pinc-software.de.
|
2005-10-17 18:01:04 +04:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
*
|
|
|
|
* Copyright 2001-2002, Travis Geiselbrecht. All rights reserved.
|
|
|
|
* Distributed under the terms of the NewOS License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2007-07-16 03:51:21 +04:00
|
|
|
#include "vfs_boot.h"
|
|
|
|
#include "vfs_net_boot.h"
|
2005-10-17 18:01:04 +04:00
|
|
|
|
|
|
|
#include <vfs.h>
|
|
|
|
#include <file_cache.h>
|
|
|
|
#include <KPath.h>
|
|
|
|
#include <syscalls.h>
|
|
|
|
#include <boot/kernel_args.h>
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
#include <util/KMessage.h>
|
2005-10-17 18:01:04 +04:00
|
|
|
#include <util/Stack.h>
|
|
|
|
|
2007-07-16 03:51:21 +04:00
|
|
|
#include <disk_device_manager/KDiskDevice.h>
|
|
|
|
#include <disk_device_manager/KDiskDeviceManager.h>
|
|
|
|
#include <disk_device_manager/KPartitionVisitor.h>
|
|
|
|
#include <DiskDeviceTypes.h>
|
|
|
|
|
|
|
|
#include <OS.h>
|
|
|
|
#include <fs_info.h>
|
|
|
|
|
|
|
|
#include <stdio.h>
|
2005-10-17 18:01:04 +04:00
|
|
|
|
|
|
|
|
|
|
|
//#define TRACE_VFS
|
|
|
|
#ifdef TRACE_VFS
|
2006-03-27 21:01:10 +04:00
|
|
|
# define TRACE(x) dprintf x
|
2005-10-17 18:01:04 +04:00
|
|
|
#else
|
2006-03-27 21:01:10 +04:00
|
|
|
# define TRACE(x) ;
|
2005-10-17 18:01:04 +04:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
typedef Stack<KPartition *> PartitionStack;
|
|
|
|
|
|
|
|
static struct {
|
|
|
|
const char *path;
|
|
|
|
const char *target;
|
|
|
|
} sPredefinedLinks[] = {
|
|
|
|
{"/system", "/boot/beos/system"},
|
|
|
|
{"/bin", "/boot/beos/bin"},
|
|
|
|
{"/etc", "/boot/beos/etc"},
|
|
|
|
{"/var", "/boot/var"},
|
|
|
|
{"/tmp", "/boot/var/tmp"},
|
|
|
|
{NULL}
|
|
|
|
};
|
|
|
|
|
|
|
|
// This can be used by other code to see if there is a boot file system already
|
|
|
|
dev_t gBootDevice = -1;
|
|
|
|
|
|
|
|
|
2007-07-16 03:51:21 +04:00
|
|
|
/*! No image was chosen - prefer disks with names like "Haiku", or "System"
|
2005-10-18 22:45:55 +04:00
|
|
|
*/
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
int
|
2005-10-18 22:45:55 +04:00
|
|
|
compare_image_boot(const void *_a, const void *_b)
|
|
|
|
{
|
|
|
|
KPartition *a = *(KPartition **)_a;
|
|
|
|
KPartition *b = *(KPartition **)_b;
|
|
|
|
|
|
|
|
if (a->ContentName() != NULL) {
|
|
|
|
if (b->ContentName() == NULL)
|
|
|
|
return 1;
|
|
|
|
} else if (b->ContentName() != NULL) {
|
|
|
|
return -1;
|
|
|
|
} else
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
int compare = strcmp(a->ContentName(), b->ContentName());
|
|
|
|
if (!compare)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!strcasecmp(a->ContentName(), "Haiku"))
|
|
|
|
return 1;
|
|
|
|
if (!strcasecmp(b->ContentName(), "Haiku"))
|
|
|
|
return -1;
|
|
|
|
if (!strncmp(a->ContentName(), "System", 6))
|
|
|
|
return 1;
|
|
|
|
if (!strncmp(b->ContentName(), "System", 6))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return compare;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-07-16 03:51:21 +04:00
|
|
|
/*! The system was booted from CD - prefer CDs over other entries. If there
|
|
|
|
is no CD, fall back to the standard mechanism (as implemented by
|
|
|
|
compare_image_boot().
|
|
|
|
*/
|
2005-10-18 22:45:55 +04:00
|
|
|
static int
|
|
|
|
compare_cd_boot(const void *_a, const void *_b)
|
|
|
|
{
|
|
|
|
KPartition *a = *(KPartition **)_a;
|
|
|
|
KPartition *b = *(KPartition **)_b;
|
|
|
|
|
|
|
|
bool aIsCD = a->Type() != NULL && !strcmp(a->Type(), kPartitionTypeDataSession);
|
|
|
|
bool bIsCD = b->Type() != NULL && !strcmp(b->Type(), kPartitionTypeDataSession);
|
|
|
|
|
|
|
|
int compare = (int)aIsCD - (int)bIsCD;
|
|
|
|
if (compare != 0)
|
|
|
|
return compare;
|
|
|
|
|
|
|
|
return compare_image_boot(_a, _b);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-07-16 03:51:21 +04:00
|
|
|
/*! Computes a check sum for the specified block.
|
|
|
|
The check sum is the sum of all data in that block interpreted as an
|
|
|
|
array of uint32 values.
|
|
|
|
Note, this must use the same method as the one used in
|
|
|
|
boot/platform/bios_ia32/devices.cpp (or similar solutions).
|
|
|
|
*/
|
2006-03-27 21:01:10 +04:00
|
|
|
static uint32
|
|
|
|
compute_check_sum(KDiskDevice *device, off_t offset)
|
|
|
|
{
|
|
|
|
char buffer[512];
|
|
|
|
ssize_t bytesRead = read_pos(device->FD(), offset, buffer, sizeof(buffer));
|
|
|
|
if (bytesRead < B_OK)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (bytesRead < (ssize_t)sizeof(buffer))
|
|
|
|
memset(buffer + bytesRead, 0, sizeof(buffer) - bytesRead);
|
|
|
|
|
|
|
|
uint32 *array = (uint32 *)buffer;
|
|
|
|
uint32 sum = 0;
|
|
|
|
|
|
|
|
for (uint32 i = 0; i < (bytesRead + sizeof(uint32) - 1) / sizeof(uint32); i++) {
|
|
|
|
sum += array[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
return sum;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
// #pragma mark - BootMethod
|
|
|
|
|
|
|
|
|
|
|
|
BootMethod::BootMethod(const KMessage& bootVolume, int32 method)
|
2007-07-16 03:51:21 +04:00
|
|
|
:
|
|
|
|
fBootVolume(bootVolume),
|
|
|
|
fMethod(method)
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
BootMethod::~BootMethod()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
status_t
|
|
|
|
BootMethod::Init()
|
|
|
|
{
|
|
|
|
return B_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// #pragma mark - DiskBootMethod
|
|
|
|
|
|
|
|
|
|
|
|
class DiskBootMethod : public BootMethod {
|
|
|
|
public:
|
|
|
|
DiskBootMethod(const KMessage& bootVolume, int32 method)
|
|
|
|
: BootMethod(bootVolume, method)
|
|
|
|
{
|
|
|
|
}
|
2006-03-27 21:01:10 +04:00
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
virtual bool IsBootDevice(KDiskDevice* device, bool strict);
|
|
|
|
virtual bool IsBootPartition(KPartition* partition, bool& foundForSure);
|
|
|
|
virtual void SortPartitions(KPartition** partitions, int32 count);
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
DiskBootMethod::IsBootDevice(KDiskDevice* device, bool strict)
|
2006-03-27 21:01:10 +04:00
|
|
|
{
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
disk_identifier *disk;
|
|
|
|
int32 diskIdentifierSize;
|
|
|
|
if (fBootVolume.FindData(BOOT_VOLUME_DISK_IDENTIFIER, B_RAW_TYPE,
|
|
|
|
(const void**)&disk, &diskIdentifierSize) != B_OK) {
|
|
|
|
dprintf("DiskBootMethod::IsBootDevice(): no disk identifier!\n");
|
|
|
|
return false;
|
|
|
|
}
|
2006-03-27 21:01:10 +04:00
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
TRACE(("boot device: bus %ld, device %ld\n", disk->bus_type,
|
|
|
|
disk->device_type));
|
2006-03-27 21:01:10 +04:00
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
switch (disk->bus_type) {
|
2006-03-27 21:01:10 +04:00
|
|
|
case PCI_BUS:
|
|
|
|
case LEGACY_BUS:
|
|
|
|
// TODO: implement this! (and then enable this feature in the boot loader)
|
|
|
|
// (we need a way to get the device_node of a device, then)
|
|
|
|
break;
|
|
|
|
|
|
|
|
case UNKNOWN_BUS:
|
|
|
|
// nothing to do here
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
switch (disk->device_type) {
|
2006-03-27 21:01:10 +04:00
|
|
|
case UNKNOWN_DEVICE:
|
|
|
|
// test if the size of the device matches
|
2006-03-29 04:16:57 +04:00
|
|
|
// (the BIOS might have given us the wrong value here, though)
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
if (strict && device->Size() != disk->device.unknown.size)
|
2006-03-27 21:01:10 +04:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// check if the check sums match, too
|
|
|
|
for (int32 i = 0; i < NUM_DISK_CHECK_SUMS; i++) {
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
if (disk->device.unknown.check_sums[i].offset == -1)
|
2006-03-27 21:01:10 +04:00
|
|
|
continue;
|
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
if (compute_check_sum(device,
|
|
|
|
disk->device.unknown.check_sums[i].offset)
|
|
|
|
!= disk->device.unknown.check_sums[i].sum) {
|
2006-03-27 21:01:10 +04:00
|
|
|
return false;
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
}
|
2006-03-27 21:01:10 +04:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ATA_DEVICE:
|
|
|
|
case ATAPI_DEVICE:
|
|
|
|
case SCSI_DEVICE:
|
|
|
|
case USB_DEVICE:
|
|
|
|
case FIREWIRE_DEVICE:
|
|
|
|
case FIBRE_DEVICE:
|
|
|
|
// TODO: implement me!
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
bool
|
|
|
|
DiskBootMethod::IsBootPartition(KPartition* partition, bool& foundForSure)
|
|
|
|
{
|
|
|
|
if (!fBootVolume.GetBool(BOOT_VOLUME_BOOTED_FROM_IMAGE, false)) {
|
|
|
|
// the simple case: we can just boot from the selected boot
|
|
|
|
// device
|
2007-07-16 19:06:02 +04:00
|
|
|
if (partition->Offset() == fBootVolume.GetInt64(
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
BOOT_VOLUME_PARTITION_OFFSET, 0)) {
|
|
|
|
foundForSure = true;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// for now, we will just collect all BFS volumes
|
|
|
|
if (fMethod == BOOT_METHOD_CD
|
|
|
|
&& fBootVolume.GetBool(BOOT_VOLUME_USER_SELECTED, false)
|
|
|
|
&& partition->Type() != NULL
|
|
|
|
&& strcmp(partition->Type(), kPartitionTypeDataSession)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (partition->ContentType() != NULL
|
|
|
|
&& !strcmp(partition->ContentType(), "Be File System")) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
DiskBootMethod::SortPartitions(KPartition** partitions, int32 count)
|
|
|
|
{
|
|
|
|
qsort(partitions, count, sizeof(KPartition *),
|
|
|
|
fMethod == BOOT_METHOD_CD ? compare_cd_boot : compare_image_boot);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// #pragma mark -
|
|
|
|
|
|
|
|
|
2007-07-16 03:51:21 +04:00
|
|
|
/*! Make the boot partition (and probably others) available.
|
|
|
|
The partitions that are a boot candidate a put into the /a partitions
|
|
|
|
stack. If the user selected a boot device, there is will only be one
|
|
|
|
entry in this stack; if not, the most likely is put up first.
|
|
|
|
The boot code should then just try them one by one.
|
|
|
|
*/
|
2005-10-17 18:01:04 +04:00
|
|
|
static status_t
|
|
|
|
get_boot_partitions(kernel_args *args, PartitionStack &partitions)
|
|
|
|
{
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
const KMessage& bootVolume = args->boot_volume;
|
|
|
|
|
|
|
|
dprintf("get_boot_partitions(): boot volume message:\n");
|
|
|
|
KMessageField field;
|
|
|
|
while (bootVolume.GetNextField(&field) == B_OK) {
|
|
|
|
type_code type = field.TypeCode();
|
|
|
|
uint32 bigEndianType = B_HOST_TO_BENDIAN_INT32(type);
|
|
|
|
dprintf("field: \"%s\", type: %.4s (0x%lx):\n", field.Name(),
|
|
|
|
(char*)&bigEndianType, type);
|
|
|
|
|
|
|
|
if (field.CountElements() == 0)
|
|
|
|
dprintf("\n");
|
|
|
|
|
|
|
|
int32 size;
|
|
|
|
for (int i = 0; const void* data = field.ElementAt(i, &size); i++) {
|
|
|
|
dprintf(" [%2d] ", i);
|
|
|
|
bool isIntType = false;
|
|
|
|
int64 intData = 0;
|
|
|
|
switch (type) {
|
|
|
|
case B_BOOL_TYPE:
|
|
|
|
dprintf("%s\n", (*(bool*)data ? "true" : "false"));
|
|
|
|
break;
|
|
|
|
case B_INT8_TYPE:
|
|
|
|
isIntType = true;
|
|
|
|
intData = *(int8*)data;
|
|
|
|
break;
|
|
|
|
case B_INT16_TYPE:
|
|
|
|
isIntType = true;
|
|
|
|
intData = *(int16*)data;
|
|
|
|
break;
|
|
|
|
case B_INT32_TYPE:
|
|
|
|
isIntType = true;
|
|
|
|
intData = *(int32*)data;
|
|
|
|
break;
|
|
|
|
case B_INT64_TYPE:
|
|
|
|
isIntType = true;
|
|
|
|
intData = *(int64*)data;
|
|
|
|
break;
|
|
|
|
case B_STRING_TYPE:
|
|
|
|
dprintf("\"%s\"\n", (char*)data);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
dprintf("data: \"%p\", %ld bytes\n", (char*)data, size);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (isIntType)
|
|
|
|
dprintf("%lld (0x%llx)\n", intData, intData);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// create boot method
|
|
|
|
int32 bootMethodType = bootVolume.GetInt32(BOOT_METHOD,
|
|
|
|
BOOT_METHOD_DEFAULT);
|
|
|
|
dprintf("get_boot_partitions(): boot method type: %ld\n", bootMethodType);
|
|
|
|
BootMethod* bootMethod = NULL;
|
|
|
|
switch (bootMethodType) {
|
|
|
|
case BOOT_METHOD_NET:
|
|
|
|
bootMethod = new(nothrow) NetBootMethod(bootVolume, bootMethodType);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case BOOT_METHOD_HARD_DISK:
|
|
|
|
case BOOT_METHOD_CD:
|
|
|
|
default:
|
|
|
|
bootMethod = new(nothrow) DiskBootMethod(bootVolume,
|
|
|
|
bootMethodType);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2007-07-16 03:51:21 +04:00
|
|
|
status_t status = bootMethod != NULL ? bootMethod->Init() : B_NO_MEMORY;
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
if (status != B_OK)
|
|
|
|
return status;
|
|
|
|
|
2005-10-17 18:01:04 +04:00
|
|
|
KDiskDeviceManager::CreateDefault();
|
|
|
|
KDiskDeviceManager *manager = KDiskDeviceManager::Default();
|
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
status = manager->InitialDeviceScan();
|
2006-05-05 14:54:10 +04:00
|
|
|
if (status != B_OK) {
|
2007-07-16 03:51:21 +04:00
|
|
|
dprintf("KDiskDeviceManager::InitialDeviceScan() failed: %s\n",
|
|
|
|
strerror(status));
|
2005-10-17 18:01:04 +04:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2007-12-26 18:25:05 +03:00
|
|
|
if (1 /* dump devices and partitions */) {
|
|
|
|
KDiskDevice *device;
|
|
|
|
int32 cookie = 0;
|
|
|
|
while ((device = manager->NextDevice(&cookie)) != NULL) {
|
|
|
|
device->Dump(true, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-10-17 18:01:04 +04:00
|
|
|
struct BootPartitionVisitor : KPartitionVisitor {
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
BootPartitionVisitor(BootMethod* bootMethod, PartitionStack &stack)
|
|
|
|
: fPartitions(stack),
|
|
|
|
fBootMethod(bootMethod)
|
|
|
|
{
|
|
|
|
}
|
2005-10-17 18:01:04 +04:00
|
|
|
|
|
|
|
virtual bool VisitPre(KPartition *partition)
|
|
|
|
{
|
|
|
|
if (!partition->ContainsFileSystem())
|
|
|
|
return false;
|
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
bool foundForSure = false;
|
|
|
|
if (fBootMethod->IsBootPartition(partition, foundForSure))
|
|
|
|
fPartitions.Push(partition);
|
2005-10-17 18:01:04 +04:00
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
// if found for sure, we can terminate the search
|
|
|
|
return foundForSure;
|
2005-10-17 18:01:04 +04:00
|
|
|
}
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
|
2005-10-17 18:01:04 +04:00
|
|
|
private:
|
|
|
|
PartitionStack &fPartitions;
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
BootMethod* fBootMethod;
|
|
|
|
} visitor(bootMethod, partitions);
|
2005-10-17 18:01:04 +04:00
|
|
|
|
2006-03-29 04:16:57 +04:00
|
|
|
bool strict = true;
|
2006-03-27 21:01:10 +04:00
|
|
|
|
2006-03-29 04:16:57 +04:00
|
|
|
while (true) {
|
|
|
|
KDiskDevice *device;
|
|
|
|
int32 cookie = 0;
|
|
|
|
while ((device = manager->NextDevice(&cookie)) != NULL) {
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
if (!bootMethod->IsBootDevice(device, strict))
|
2006-03-29 04:16:57 +04:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (device->VisitEachDescendant(&visitor) != NULL)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!partitions.IsEmpty() || !strict)
|
2005-10-17 18:01:04 +04:00
|
|
|
break;
|
2006-03-29 04:16:57 +04:00
|
|
|
|
|
|
|
// we couldn't find any potential boot devices, try again less strict
|
|
|
|
strict = false;
|
2005-10-17 18:01:04 +04:00
|
|
|
}
|
|
|
|
|
[Sorry, couldn't split this one up any further.]
* Images preloaded by the boot loader had to be modules to be of any use
to the kernel. Extended the mechanism so that any images not accepted
by the module code would later be tried to be added as drivers by the
devfs. This is a little hacky ATM, since the devfs manages the drivers
using a hash map keyed by the drivers inode ID, which those drivers
obviously don't have.
* The devfs emulates read_pages() using read(), if the device driver
doesn't implement the former (all old-style drivers), thus making it
possible to BFS, which uses the file cache which in turn requires
read_pages(), on the device. write_pages() emulation is still missing.
* Replaced the kernel_args::boot_disk structure by a KMessage, which can
more flexibly be extended and deals more gracefully with
arbitrarily-size data. The disk_identifier structure still exists,
though. It is added as message field in cases where needed (non net
boot). Moved the boot_drive_number field of the bios_ia32 platform
specific args into the message.
* Made the stage 1 PXE boot loader superfluous. Moved the relevant
initialization code into the stage 2 loader, which can now be loaded
directly via PXE.
* The PXE boot loader does now download a boot tgz archive via TFTP. It
does no longer use the RemoteDisk protocol (it could actually be
removed from the boot loader). It also parses the DHCP options in the
DHCPACK packet provided by PXE and extracts the root path to be
mounted by the kernel.
* Reorganized the boot volume search in the kernel (vfs_boot.cpp) and
added support for network boot. In this case the net stack is
initialized and the network interface the boot loader used is brought
up and configured. Since NBD and RemoteDisk are our only options for
net boot (and those aren't really configurable dynamically) ATM, the
the boot device is found automatically by the disk device manager.
Booting via PXE does work to some degree now. The most grievous problem
is that loading certain drivers or kernel modules (or related activity)
causes a reboot (likely a triple fault, though one wonders where our
double fault handler is on vacation). Namely the keyboard and mouse input
server add-ons need to be deactivated as well as the media server.
A smaller problem is the net server, which apparently tries to
(re-)configure the network interface we're using to boot, which
obviously doesn't work out that well. So, if all this stuff is disabled
Haiku does fully boot, when using the RemoteDisk protocol (not being
able to use keyboard or mouse doesn't make this a particular fascinating
experience, though ;-)). I had no luck with NBD -- it seemed to have
protocol problems with the servers I tried.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21611 a95241bf-73f2-0310-859d-f6bbb57e9c96
2007-07-15 06:10:15 +04:00
|
|
|
// sort partition list (e.g.. when booting from CD, CDs should come first in
|
|
|
|
// the list)
|
|
|
|
if (!args->boot_volume.GetBool(BOOT_VOLUME_USER_SELECTED, false))
|
|
|
|
bootMethod->SortPartitions(partitions.Array(), partitions.CountItems());
|
2005-10-18 22:45:55 +04:00
|
|
|
|
2005-10-17 18:01:04 +04:00
|
|
|
return B_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// #pragma mark -
|
|
|
|
|
|
|
|
|
|
|
|
status_t
|
|
|
|
vfs_bootstrap_file_systems(void)
|
|
|
|
{
|
|
|
|
status_t status;
|
|
|
|
|
|
|
|
// bootstrap the root filesystem
|
2006-02-20 21:04:27 +03:00
|
|
|
status = _kern_mount("/", NULL, "rootfs", 0, NULL, 0);
|
2005-10-17 18:01:04 +04:00
|
|
|
if (status < B_OK)
|
|
|
|
panic("error mounting rootfs!\n");
|
|
|
|
|
|
|
|
_kern_setcwd(-1, "/");
|
|
|
|
|
|
|
|
// bootstrap the devfs
|
|
|
|
_kern_create_dir(-1, "/dev", 0755);
|
2006-02-20 21:04:27 +03:00
|
|
|
status = _kern_mount("/dev", NULL, "devfs", 0, NULL, 0);
|
2005-10-17 18:01:04 +04:00
|
|
|
if (status < B_OK)
|
|
|
|
panic("error mounting devfs\n");
|
|
|
|
|
|
|
|
// bootstrap the pipefs
|
|
|
|
_kern_create_dir(-1, "/pipe", 0755);
|
2006-02-20 21:04:27 +03:00
|
|
|
status = _kern_mount("/pipe", NULL, "pipefs", 0, NULL, 0);
|
2005-10-17 18:01:04 +04:00
|
|
|
if (status < B_OK)
|
|
|
|
panic("error mounting pipefs\n");
|
|
|
|
|
2005-10-31 02:00:14 +03:00
|
|
|
// create directory for the boot volume
|
2005-10-17 18:01:04 +04:00
|
|
|
_kern_create_dir(-1, "/boot", 0755);
|
|
|
|
|
|
|
|
// create some standard links on the rootfs
|
|
|
|
|
|
|
|
for (int32 i = 0; sPredefinedLinks[i].path != NULL; i++) {
|
|
|
|
_kern_create_symlink(-1, sPredefinedLinks[i].path,
|
|
|
|
sPredefinedLinks[i].target, 0);
|
|
|
|
// we don't care if it will succeed or not
|
|
|
|
}
|
|
|
|
|
|
|
|
return B_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-01-12 21:09:15 +03:00
|
|
|
void
|
2005-10-17 18:01:04 +04:00
|
|
|
vfs_mount_boot_file_system(kernel_args *args)
|
|
|
|
{
|
|
|
|
PartitionStack partitions;
|
|
|
|
status_t status = get_boot_partitions(args, partitions);
|
2005-10-25 02:12:41 +04:00
|
|
|
if (status < B_OK) {
|
2007-01-12 21:09:15 +03:00
|
|
|
panic("get_boot_partitions failed!");
|
|
|
|
}
|
|
|
|
if (partitions.IsEmpty()) {
|
|
|
|
panic("did not find any boot partitions!");
|
2005-10-25 02:12:41 +04:00
|
|
|
}
|
2005-10-17 18:01:04 +04:00
|
|
|
|
|
|
|
KPartition *bootPartition;
|
|
|
|
while (partitions.Pop(&bootPartition)) {
|
|
|
|
KPath path;
|
|
|
|
if (bootPartition->GetPath(&path) != B_OK)
|
|
|
|
panic("could not get boot device!\n");
|
|
|
|
|
2007-01-12 21:09:15 +03:00
|
|
|
TRACE(("trying to mount boot partition: %s\n", path.Path()));
|
2006-02-20 21:04:27 +03:00
|
|
|
gBootDevice = _kern_mount("/boot", path.Path(), NULL, 0, NULL, 0);
|
2005-10-17 18:01:04 +04:00
|
|
|
if (gBootDevice >= B_OK)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gBootDevice < B_OK)
|
|
|
|
panic("could not mount boot device!\n");
|
|
|
|
|
|
|
|
// create link for the name of the boot device
|
|
|
|
|
|
|
|
fs_info info;
|
|
|
|
if (_kern_read_fs_info(gBootDevice, &info) == B_OK) {
|
|
|
|
char path[B_FILE_NAME_LENGTH + 1];
|
|
|
|
snprintf(path, sizeof(path), "/%s", info.volume_name);
|
|
|
|
|
|
|
|
_kern_create_symlink(-1, path, "/boot", 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
file_cache_init_post_boot_device();
|
2006-09-04 17:10:08 +04:00
|
|
|
|
|
|
|
// search for other disk systems
|
|
|
|
KDiskDeviceManager *manager = KDiskDeviceManager::Default();
|
|
|
|
manager->RescanDiskSystems();
|
2008-04-03 22:14:11 +04:00
|
|
|
manager->StartMonitoring();
|
2005-10-17 18:01:04 +04:00
|
|
|
}
|
|
|
|
|