Re: booting from gpt/raid?
On Thu 05 Jul 2018 at 10:52:12 +0300, Andreas Gustafsson wrote:
> MLH wrote:
> > Boot Options are:
> > Hard Drive, CDROM, USB-FDD, USB-ZIP, USB-CDROM, USB-HDD, Legacy LAN
>
> A USB memory stick emulates a hard drive, so USB-HDD should work.
A USB stick formatted like a hard drive *should* always work.
Many BIOSes also allow booting from a USB stick formatted as a cdrom,
i.e. filled with an .iso image.
Here is a script I once made to create a bootable dvd from the install
sets. I made it to have a non-standard live and install dvd that also
includes all sources. I had also been trying to include (apart from the
amd64 version) i386 and VAX on the same dvd, but I didn't get far with
that.
This one was working for 7.1.1/amd64.
#!/bin/sh
# Make a bootable cd for amd64.
# If the same method works for VAX, I have to look into.
#
#set -x
arch=amd64
sets="kern-GENERIC modules base comp etc games man misc text"
xsets="xbase xcomp xetc xfont xserver"
work=work.$arch
top=$(pwd)
what=${top##*/}
mkdir $work
cd $work
umask
echo "Creating a ${what} dvd image:"
for set in $sets $xsets
do
echo "Extracting ${set} (using chroot)..."
tar --chroot -x -p -z -f $top/$arch/binary/sets/${set}.tgz
done
# Put bootfiles in place:
# For amd64:
cp -p ./usr/mdec/boot .
cp -p ./usr/mdec/bootxx_cd9660 ./bootxx_cd9660.${arch}
cat >boot.cfg etc/rc.d/filltmpfs <<'EOF'
# PROVIDE: filltmpfs
# REQUIRE: root
# BEFORE: mountcritlocal
$_rc_subr_loaded . /etc/rc.subr
name="filltmpfs"
rcvar="filltmpfs"
start_cmd="filltmpfs_start"
stop_cmd=":"
filltmpfs_start()
{
# hack to get around bugs in kernfs's rootdev/rrootdev lookup.
ls -l /dev/* > /dev/null 2>&1
# prepare important directories in the tmpfses, so dhcpcd and vi will work
echo "Prepare important directories in the tmpfses, so dhcpcd and vi will
work."
mount_critical_filesystems local
/bin/mkdir -p /var/run /var/db /var/log /var/tmp /var/spool /var/cron
touch /var/log/messages /var/log/authlog /var/log/cron /var/log/xferlog
touch /var/log/lpd-errs /var/log/maillog
}
load_rc_config $name
run_rc_command "$1"
EOF
chmod a+x etc/rc.d/filltmpfs
cat >etc/fstab <>etc/rc.conf <<'EOF'
critical_filesystems_local="$critical_filesystems_local /tmp"
rc_configured=YES
filltmpfs=YES
mountall=YES
hostname="installer"
postfix=NO
no_swap=YES
wscons=YES
EOF
sed etc/ttys.new \
-e '/^console/s/on /off /' \
-e '/^ttyE/s/off /on /'
mv etc/ttys.new etc/ttys
mkdir mnt2 targetroot kern proc
ln -s . release
echo "Link in distribution:"
ln ${top}/CHANGES* ${top}/LAST_MINUTE ${top}/README.files .
(cd ${top}; find ${arch} source shared -type d ) |
while read dir
do
echo "${dir}"
mkdir -p ${dir}
ln ${top}/${dir}/* ${dir}/ 2>/dev/null
done
cd dev
rm -f console # force the system to make a tmpfs /dev
# ./MAKEDEV all
cd ..
echo "Creating the iso image..."
makefs -t cd9660 \
-o
"bootimage=i386;usr/mdec/bootxx_cd9660,no-emul-boot,rockridge,allow-deep-trees,allow-multidot,volumeid=${what}.${arch}"
\
${top}/live-and-install.$arch.iso .
cd $top
echo "Testing the image:"
echo dd if=/dev/zero of=disk.img bs=1m count=1536
echo qemu-system-x86_64 -cdrom boot.amd64.iso -drive
file=disk.img,index=0,media=disk,format=raw # -netdev user,id=mynet0 -device
e1000,netdev=mynet0
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
Re: booting from gpt/raid?
On 07/11/18 21:58, MLH wrote:
Unfortunately, gpt-on-raid1-on-gpt is not bootable, as opposed to
disklabel-on-RAID1-on-disklabel (which has size limitations).
The mbr boot code is able to account for disklabel-on-raid1, but not for
gpt-on-raid1, see e.g. install/44982.
>
I'm not quite sure I am understanding your nomenclature here.
I don't blame you.
Think of it as an onion.
You start by putting gpts / disklabels on two empty disks, then create a
partition designated as type raid on each. You configure the raid1,
which sets up its own header at the beginning of the partition, and then
create another ("inner") gpt / disklabel on the resulting raid device.
Now, the MBR boot sector code knows how to parse the outer gpt /
disklabel for a partition marked 'bootable', then load and execute its
first block (the PBR). The PBR code knows how to recognize a BSD
disklabel raid partition and skip the fixed-size raid header[1], which
requires a disklabel right at the start of the raid.
But as it is, the PBR code does not know how to find the inner gpt in
presence of a raid header. ISTR this was because of variable size of
on-disk structures, but my memory is hazy.
Cheerio,
hauke
[1] see comment at the beginning of
,
and
.
--
The ASCII Ribbon CampaignHauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-21344
Re: booting from gpt/raid?
Hauke Fath wrote: > On 07/01/18 22:55, MLH wrote: > > Things are generally going well but before I actually install a > > system, one question I have is how to make the configuration > > bootable. > > Unfortunately, gpt-on-raid1-on-gpt is not bootable, as opposed to > disklabel-on-RAID1-on-disklabel (which has size limitations). > > The mbr boot code is able to account for disklabel-on-raid1, but not for > gpt-on-raid1, see e.g. install/44982. I'm not quite sure I am understanding your nomenclature here. Thanks for all who attempted to assist with creating an EFI bootable system. I have supposedly made EFI bootable systems on USB drives, hard drives and cdrom and none of them boot with this motherboard so I'll got back to trying disklabel-on-gpt then raid-on-gpt. As in a disklabel gpt partition, maybe a swap on a second gpt partition, then raid1 on a third gpt partition (for both big drives) unless this doesn't work on NetBSD.
Re: booting from gpt/raid?
On Thu, 5 Jul 2018, Thomas Mueller wrote: I remember seeing something in (I believe it was Syslinux) about formatting/partitioning a USB stick to make it look like an Iomega Zip drive. Does anybody still make floppy disks, or USB floppy drives? Modern motherboards have no floppy headers. I browsed iomega.com and got a domain-parking site (Iomega is no longer there). Iomega got aquired by EMC in 2008. -- Michael Parson Pflugerville, TX KF5LGQ
Re: booting from gpt/raid?
In article , Hauke Fath wrote: | >Unfortunately, gpt-on-raid1-on-gpt is not bootable, as opposed to | >disklabel-on-RAID1-on-disklabel (which has size limitations). Date:Fri, 6 Jul 2018 11:48:01 + (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | | Mine works... The trick is to use a umass sd0 to boot from :-)
Re: booting from gpt/raid?
In article , Hauke Fath wrote: >On 07/01/18 22:55, MLH wrote: >> Things are generally going well but before I actually install a >> system, one question I have is how to make the configuration >> bootable. > >Unfortunately, gpt-on-raid1-on-gpt is not bootable, as opposed to >disklabel-on-RAID1-on-disklabel (which has size limitations). Mine works... The trick is to use a umass sd0 to boot from :-) christos [...] [1.710175] wd0 at atabus1 drive 1 [1.710175] wd0: [1.710175] wd0: drive supports 16-sector PIO transfers, LBA48 addressing [1.710175] wd0: 2794 GB, 5814021 cyl, 16 head, 63 sec, 512 bytes/sect x 5860533168 sectors [1.740187] wd0: GPT GUID: b9dd57fb-9dea-4bd4-98d3-ce1c0ccff5f4 [1.750191] dk0 at wd0: "raid0.0", 5860531200 blocks at 1024, type: raidframe [1.750191] wd0: 32-bit data port [1.750191] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) [1.750191] wd0(piixide0:0:1): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA), WRITE DMA FUA EXT [3.890025] umass0 at uhub5 port 4 configuration 1 interface 0 [3.890025] umass0: SanDisk (0x781) Cruzer Fit (0x5571), rev 2.00/1.27, addr 2 [3.890025] umass0: using SCSI over Bulk-Only [3.890025] scsibus0 at umass0: 2 targets, 1 lun per target [3.890025] sd0 at scsibus0 target 0 lun 0: disk removable [3.890025] sd0: 30532 MB, 62034 cyl, 16 head, 63 sec, 512 bytes/sect x 62530624 sectors [3.909860] dk1 at sd0: "sd0a", 62530561 blocks at 63, type: ffs [4.199655] ehci0: handing over low speed device on port 6 to uhci2 [4.719361] wd1 at atabus2 drive 0 [4.719361] wd1: [4.719361] wd1: drive supports 16-sector PIO transfers, LBA48 addressing [4.719361] wd1: 2794 GB, 5814021 cyl, 16 head, 63 sec, 512 bytes/sect x 5860533168 sectors [4.759314] wd1: GPT GUID: ee945b1e-2d48-4d47-81f2-8fb1c17effa8 [4.759314] dk2 at wd1: "raid0.1", 5860531200 blocks at 1024, type: raidframe [4.759314] wd1: 32-bit data port [4.769299] wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) [4.769299] wd1(piixide0:1:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA), WRITE DMA FUA EXT [4.808910] Component on: dk0: 5860531200 [4.808910] Row: 0 Column: 0 Num Rows: 1 Num Columns: 2 [4.808910] Version: 2 Serial Number: 2016042301 Mod Counter: 4985 [4.808910] Clean: Yes Status: 0 [4.808910] sectPerSU: 128 SUsPerPU: 1 SUsPerRU: 1 [4.808910] RAID Level: 1 blocksize: 512 numBlocks: 5860531072 [4.808910] Autoconfig: Yes [4.808910] Root partition: Force [4.808910] Last configured as: raid0 [4.808910] Component on: dk2: 5860531200 [4.808910] Row: 0 Column: 1 Num Rows: 1 Num Columns: 2 [4.808910] Version: 2 Serial Number: 2016042301 Mod Counter: 4985 [4.808910] Clean: Yes Status: 0 [4.808910] sectPerSU: 128 SUsPerPU: 1 SUsPerRU: 1 [4.808910] RAID Level: 1 blocksize: 512 numBlocks: 5860531072 [4.808910] Autoconfig: Yes [4.808910] Root partition: Force [4.808910] Last configured as: raid0 [4.828722] Found: dk0 at 0 [4.828722] Found: dk2 at 1 [4.828722] RAID autoconfigure [4.828722] Configuring raid0: [4.828722] Starting autoconfiguration of RAID set... [4.828722] Looking for 0 in autoconfig [4.828722] Found: dk0 at 0 [4.828722] Looking for 1 in autoconfig [4.828722] Found: dk2 at 1 [4.828722] raid0: allocating 20 buffers of 65536 bytes. [4.828722] raid0: RAID Level 1 [4.828722] raid0: Components: /dev/dk0 /dev/dk2 [4.828722] raid0: Total Sectors: 5860531072 (2861587 MB) [4.838659] raid0: GPT GUID: 2f48057f-f281-485e-a11d-8f1eb6a9293d [4.838659] dk3 at raid0: "root", 1024000 blocks at 34, type: ffs [4.838659] dk4 at raid0: "swap", 16777216 blocks at 1024034, type: swap [4.838659] dk5 at raid0: "usr", 125829120 blocks at 17801250, type: ffs [4.838659] dk6 at raid0: "var", 62914560 blocks at 143630370, type: ffs [4.838659] dk7 at raid0: "src-7", 125829120 blocks at 206544930, type: ffs [4.838659] dk8 at raid0: "u-7", 125829120 blocks at 332374050, type: ffs [4.838659] dk9 at raid0: "backup-7", 5402327869 blocks at 458203170, type: ffs [4.838659] boot device: dk3 [4.838659] root on dk3 dumps on dk4 [4.848556] dump_misc_init: max_paddr = 0x14000 [4.848556] mountroot: trying lfs... [4.848556] mountroot: trying ext2fs... [4.848556] mountroot: trying ffs... [4.858454] root file system type: ffs [4.858454] kern.module.path=/stand/amd64/8.99.15/modules [4.868439] init: copying out path `/sbin/init' 11
Re: booting from gpt/raid?
On 07/01/18 22:55, MLH wrote: Things are generally going well but before I actually install a system, one question I have is how to make the configuration bootable. Unfortunately, gpt-on-raid1-on-gpt is not bootable, as opposed to disklabel-on-RAID1-on-disklabel (which has size limitations). The mbr boot code is able to account for disklabel-on-raid1, but not for gpt-on-raid1, see e.g. install/44982. Cheerio, hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: booting from gpt/raid?
On Thu, Jul 05, 2018 at 07:09:27PM -0400, MLH wrote: > Thomas Mueller wrote: > > Does CDROM on your boot options include DVD? > > Yes. That's what I used to recover my temp boot disk and it works > great. In a separate message I mentioned I was attempting to build > a custom Live DVD but I can't figure out the new way of creating > a bootable CD/DVD since floppy boot images are gone and the Live > images build.sh builds are not isos. > > Anyone know it's done now? FWIW, I added support for booting from CDROM to grub long years ago and had, at that occasion, read the El Torito spec. If I remember correctly, there was not only the possibility to emulate a floppy (with whatever standard floppy size; generally, the distributions used the 2.88Mb format) but there was a HD feature: the image, of whatever size, was used as a disk. 10 or more years ago, it was not widely supported by BIOSes. I guess it is now supported and distributions use this feature instead of trying to fit the kernel with its embedded root filesystem in constrained sizes. OTH, -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: booting from gpt/raid?
from MLH: > Thomas Mueller wrote: > > Does CDROM on your boot options include DVD? > Yes. That's what I used to recover my temp boot disk and it works > great. In a separate message I mentioned I was attempting to build > a custom Live DVD but I can't figure out the new way of creating > a bootable CD/DVD since floppy boot images are gone and the Live > images build.sh builds are not isos. > Anyone know it's done now? You can look in $SRCDIR/distrib/amd64 , and there are various images you can make, including cdroms, and other architectures besides amd64 in distrib subdirectory. root@amelia:/lin1/arbor # ls -l /media/zip1/usr/src/distrib/amd64 total 20 drwxr-xr-x 2 root wheel 512 Jun 29 06:50 CVS -rw-r--r-- 1 root wheel 567 May 23 2017 Makefile drwxr-xr-x 6 root wheel 512 May 14 2017 cdroms drwxr-xr-x 3 root wheel 512 Oct 1 2017 installimage drwxr-xr-x 3 root wheel 512 Jun 7 2014 instkernel drwxr-xr-x 3 root wheel 512 Jun 7 2014 kmod drwxr-xr-x 3 root wheel 512 Jun 7 2014 kmod-cgdroot drwxr-xr-x 5 root wheel 512 Jun 7 2014 liveimage drwxr-xr-x 6 root wheel 512 May 23 2017 ramdisks drwxr-xr-x 3 root wheel 512 Apr 3 10:20 uefi-installimage > It is working now. It takes just under 12 minutes to start loading > /netbsd off of the temp wd0a from the live-sd0 img dd'ed to a usb > stick. > While not very convenient, it's workable. Still would like to get > the live image booting from a dvd. Would be immensely quicker. Booting from USB is much faster than this on my computer. Installing is what is slow. Tom
Re: booting from gpt/raid?
MLH wrote: > Andreas Gustafsson wrote: > > MLH wrote: > > > Boot Options are: > > > Hard Drive, CDROM, USB-FDD, USB-ZIP, USB-CDROM, USB-HDD, Legacy LAN > > > > A USB memory stick emulates a hard drive, so USB-HDD should work. > > I tried it again and apparently I didn't wait long enough before. > After about five minutes, it loads the NetBSD boot loader but after > about 10 minutes more it gets an I/O error so I'll try to investigate > that. It is working now. It takes just under 12 minutes to start loading /netbsd off of the temp wd0a from the live-sd0 img dd'ed to a usb stick. While not very convenient, it's workable. Still would like to get the live image booting from a dvd. Would be immensely quicker. Thanks to all
Re: booting from gpt/raid?
Thomas Mueller wrote: > Does CDROM on your boot options include DVD? Yes. That's what I used to recover my temp boot disk and it works great. In a separate message I mentioned I was attempting to build a custom Live DVD but I can't figure out the new way of creating a bootable CD/DVD since floppy boot images are gone and the Live images build.sh builds are not isos. Anyone know it's done now?
Re: booting from gpt/raid?
from MLH: > Andreas Gustafsson wrote: > > MLH wrote: > > > Boot Options are: > > > Hard Drive, CDROM, USB-FDD, USB-ZIP, USB-CDROM, USB-HDD, Legacy LAN > > A USB memory stick emulates a hard drive, so USB-HDD should work. > I tried it again and apparently I didn't wait long enough before. > After about five minutes, it loads the NetBSD boot loader but after > about 10 minutes more it gets an I/O error so I'll try to investigate > that. My MSI motherboards have LAN and PXE boot, but I don't think the LAN is legacy. You could possibly try USB-FDD or USB-ZIP, but these might have different disk formats. I remember seeing something in (I believe it was Syslinux) about formatting/partitioning a USB stick to make it look like an Iomega Zip drive. Does anybody still make floppy disks, or USB floppy drives? Modern motherboards have no floppy headers. I browsed iomega.com and got a domain-parking site (Iomega is no longer there). My experience with Gigabyte is less than favorable. Does CDROM on your boot options include DVD? Tom
Re: booting from gpt/raid?
Andreas Gustafsson wrote: > MLH wrote: > > Boot Options are: > > Hard Drive, CDROM, USB-FDD, USB-ZIP, USB-CDROM, USB-HDD, Legacy LAN > > A USB memory stick emulates a hard drive, so USB-HDD should work. I tried it again and apparently I didn't wait long enough before. After about five minutes, it loads the NetBSD boot loader but after about 10 minutes more it gets an I/O error so I'll try to investigate that. Thanks
Re: booting from gpt/raid?
MLH wrote: > Boot Options are: > Hard Drive, CDROM, USB-FDD, USB-ZIP, USB-CDROM, USB-HDD, Legacy LAN A USB memory stick emulates a hard drive, so USB-HDD should work. -- Andreas Gustafsson, g...@gson.org
Re: booting from gpt/raid?
My HP Envy laptop boots netbsd in both efi and bios modes, from internal sata disk and external usb one. Both modes are enabled simultaneously. My default efi boot is rEFInd, works fine for me. I installed NetBSD-current on some free space at the end of a gpt disk which already contained a couple of Linux distributions and some Windows data, following the outline described above. rEFInd also automatically recognises other systems on external disks and can boot them (usually; in some cases this didn't work, e.g. with a Fedora on some external mbr disk, in which case I had to get in front of rEFInd with F9 and choose the disk directly). So obviously it depends on the bios/efi capabilities. On Wed, 4 Jul 2018 at 08:51, Thomas Mueller wrote: > from MLH: > > > Well, not so great. Once the bios detects an EFI boot drive on the > > system, it attempts to load that, regardless of any other non-EFI > > boot drive you specify. So to boot from the temp non-EFI boot drive, > > the EFI drives have to be disconnected until the NetBSD boot loader > > has started and then I apply power to the EFI drives to bring them > > up and then boot NetBSD. > > > Somewhere in that scenario, to boot from the non-EFI drive, NetBSD > > started requiring to run /var/run/lvm and it wouldn't run. The > > only way I could boot from that drive was to 'update' the os from > > cd again, so something apparently got hosed. No idea what. > > > Needless to say, the EFI drives didn't boot. Not sure why yet. > > "Booting Operating System" showed then the cursor moved down, > > possibly attempting to display something, then kept cycling back > > and from bwtween those two. > > My systems have UEFI, but I can boot USB sticks in non-EFI mode. > > I can boot the System Rescue CD either way (UEFI or non-UEFI), written to > USB stick. > > Maybe it depends on the motherboard? > > Tom >
Re: booting from gpt/raid?
Thomas Mueller wrote: > from MLH: > > > Scratch the request for usb stick boot. My motherboard doesn't > > appear to allow it. I'll see if I can build a cd that I can boot > > off of and transfer to the hard drive for the system. > > > Thanks anyway > > I thought all modern PC motherboards could boot from USB stick. This is a Gigabyte from around 2012/2013 IIRC. > What do you see when you reboot and go into the UEFI setup and configuration? UEFI configuration shows only CD/DVD boot and as mentioned before, only implies UEFI hard drive boot. > How are you supposed to install any OS, including MS-Windows, starting from a > blank hard drive? > How are you supposed to recover if something happens and you can't boot from > the hard disk? Boot Options are: Hard Drive, CDROM, USB-FDD, USB-ZIP, USB-CDROM, USB-HDD, Legacy LAN > Are you not able to boot from any USB port? Apparently not from a memory stick
Re: booting from gpt/raid?
from MLH: > Scratch the request for usb stick boot. My motherboard doesn't > appear to allow it. I'll see if I can build a cd that I can boot > off of and transfer to the hard drive for the system. > Thanks anyway I thought all modern PC motherboards could boot from USB stick. What do you see when you reboot and go into the UEFI setup and configuration? How are you supposed to install any OS, including MS-Windows, starting from a blank hard drive? How are you supposed to recover if something happens and you can't boot from the hard disk? Are you not able to boot from any USB port? Better to respond to the list than to me alone. That way, you can benefit by other people's insights. Tom
Re: booting from gpt/raid?
Thomas Mueller wrote: > from MLH: > > > Needless to say, the EFI drives didn't boot. Not sure why yet. > > "Booting Operating System" showed then the cursor moved down, > > possibly attempting to display something, then kept cycling back > > and from bwtween those two. > > My systems have UEFI, but I can boot USB sticks in non-EFI mode. > > I can boot the System Rescue CD either way (UEFI or non-UEFI), written to USB > stick. So I built a *live-wd0root.img, installed that on a usb stick and apparently my motherboard doesn't allow booting from usb stick. So I decided to make a rescue or live cd iso (so I could boot from cd and transfer to the temp boot drive) and neither are build.sh options (the iso). And since floppy boot has been removed, the old method: mkisofs -o output.iso -b i386/installation/floppy/boot-big.fs \ -c boot.catalog -l -J -R -allow-leading-dots /cdsources as described in https://www.netbsd.org/docs/bootcd.html#cdrecord no longer works. It appears that the new method uses cdboot, but I can't determine exactly how to make and use that. Would be nice if https://www.netbsd.org/docs/bootcd.html was updated to reflect how to build bootable cds now.
Re: booting from gpt/raid?
from MLH: > Well, not so great. Once the bios detects an EFI boot drive on the > system, it attempts to load that, regardless of any other non-EFI > boot drive you specify. So to boot from the temp non-EFI boot drive, > the EFI drives have to be disconnected until the NetBSD boot loader > has started and then I apply power to the EFI drives to bring them > up and then boot NetBSD. > Somewhere in that scenario, to boot from the non-EFI drive, NetBSD > started requiring to run /var/run/lvm and it wouldn't run. The > only way I could boot from that drive was to 'update' the os from > cd again, so something apparently got hosed. No idea what. > Needless to say, the EFI drives didn't boot. Not sure why yet. > "Booting Operating System" showed then the cursor moved down, > possibly attempting to display something, then kept cycling back > and from bwtween those two. My systems have UEFI, but I can boot USB sticks in non-EFI mode. I can boot the System Rescue CD either way (UEFI or non-UEFI), written to USB stick. Maybe it depends on the motherboard? Tom
Re: booting from gpt/raid?
MLH wrote: > Robert Elz wrote: > > | The motherboard supposedly autodetects either efi or bios boot so > > | I thought I might just go with efi first. > > > > That's interesting, as it is possible to have both setup... I wonder > > which it chooses then? > > Actually the manual isn't clear : > > - EFI CD/DVD Boot Option > Set the item to EFI if you want to install the operating system > to a hard drive larger that 2.2TB. Make sure the operating system > to be installed supports booting from a GPT partition, such as > Windows 7 64-bit and Windows Server 2003 64-bit. Auto lets the > BIOS automatically configure this setting depending on the hard > drive you install (Default: Auto). > > So it sounds like it is giving you an EFI option to do an EFI > install from CD/DVD, whereupon it can then boot from a GPT-EFI boot > partition using the Auto option. Well, not so great. Once the bios detects an EFI boot drive on the system, it attempts to load that, regardless of any other non-EFI boot drive you specify. So to boot from the temp non-EFI boot drive, the EFI drives have to be disconnected until the NetBSD boot loader has started and then I apply power to the EFI drives to bring them up and then boot NetBSD. Somewhere in that scenario, to boot from the non-EFI drive, NetBSD started requiring to run /var/run/lvm and it wouldn't run. The only way I could boot from that drive was to 'update' the os from cd again, so something apparently got hosed. No idea what. Needless to say, the EFI drives didn't boot. Not sure why yet. "Booting Operating System" showed then the cursor moved down, possibly attempting to display something, then kept cycling back and from bwtween those two.
Re: booting from gpt/raid?
Robert Elz wrote: > | The motherboard supposedly autodetects either efi or bios boot so > | I thought I might just go with efi first. > > That's interesting, as it is possible to have both setup... I wonder > which it chooses then? Actually the manual isn't clear : - EFI CD/DVD Boot Option Set the item to EFI if you want to install the operating system to a hard drive larger that 2.2TB. Make sure the operating system to be installed supports booting from a GPT partition, such as Windows 7 64-bit and Windows Server 2003 64-bit. Auto lets the BIOS automatically configure this setting depending on the hard drive you install (Default: Auto). So it sounds like it is giving you an EFI option to do an EFI install from CD/DVD, whereupon it can then boot from a GPT-EFI boot partition using the Auto option. I thought I would install efi boot only first and see what happens. Back up if that doesn't work. > The one thing to watch with UEFI booting is that the firmware seems > to be less likely to configure all the hardware than it used to with > BIOS booting - some systems fail to boot in UEFI mode (or some > hardware is not detected, or does not work) which all work fine in > BIOS mode. It is better in recent -current but still not perfect. > > | The url above plus Robert's and Greg's instructions have me this > | far (wd2 shown only and doesn't include raid components yet): > > All looks OK to me (as far as it goes.) Ok. Thanks. I'll proceed
Re: booting from gpt/raid?
Date:Mon, 2 Jul 2018 21:55:34 -0400 (EDT) From:m...@goathill.org (MLH) Message-ID: <20180703015534.336c612...@chopper.goathill.org> | The motherboard supposedly autodetects either efi or bios boot so | I thought I might just go with efi first. That's interesting, as it is possible to have both setup... I wonder which it chooses then? The one thing to watch with UEFI booting is that the firmware seems to be less likely to configure all the hardware than it used to with BIOS booting - some systems fail to boot in UEFI mode (or some hardware is not detected, or does not work) which all work fine in BIOS mode. It is better in recent -current but still not perfect. | The url above plus Robert's and Greg's instructions have me this | far (wd2 shown only and doesn't include raid components yet): All looks OK to me (as far as it goes.) kre
Re: booting from gpt/raid?
m...@netbsd.org wrote: > This guide might be helpful for you > https://wiki.netbsd.org/users/spz/moderndisk/ The motherboard supposedly autodetects either efi or bios boot so I thought I might just go with efi first. The url above plus Robert's and Greg's instructions have me this far (wd2 shown only and doesn't include raid components yet): gpt create wd2 gpt add -l uefiboot1 -s 20M -t efi wd2 gpt add -l boot_1 -t ffs -s 128M wd2 gpt add -s 7813733997 -l raid_1 -t raid wd2 --- # gpt show -l wd2 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 40960 1 GPT part - uefiboot1 40994 262144 2 GPT part - boot_1 303138 7813733997 3 GPT part - raid_1 7814037135 32 Sec GPT table 7814037167 1 Sec GPT header # dkctl wd2 listwedges /dev/rwd2: 3 wedges: dk0: uefiboot1, 40960 blocks at 34, type: msdos dk1: 377f97f5-4d8c-4381-a0ac-d1e8f207d5fc, 262144 blocks at 40994, type: ffs dk2: 983e31c6-c0d0-465b-8389-ffde60980239, 7813733997 blocks at 303138, type: raidframe --- newfs_msdos -F 16 -b 1024 /dev/rdk0 mount name=uefiboot1 /mnt mkdir -p /mnt/EFI/boot cp /usr/mdec/*.efi /mnt/EFI/boot cat > /mnt/boot.cfg menu=Boot normally:dev hd0b:;rndseed /entropy/entropy-file;boot hd0b:netbsd menu=Boot single user:dev hd0b:;rndseed /entropy/entropy-file;boot hd0b:netbsd -s menu=Drop to boot prompt:prompt default=1 timeout=5 clear=1 ^D umount /mnt newfs -O2 dk1 mount /dev/dk1 /mnt cat > /mnt/boot.cfg menu=Boot normally:dev hd0b:;rndseed /entropy/entropy-file;boot hd0b:netbsd menu=Boot single user:dev hd0b:;rndseed /entropy/entropy-file;boot hd0b:netbsd -s menu=Boot normally from hd1b:dev hd1b:;rndseed /entropy/entropy-file;boot hd1b:netbsd menu=Boot single user from hd1b:dev hd1b:;rndseed /entropy/entropy-file;boot hd1b:netbsd -s menu=Drop to boot prompt:prompt default=1 timeout=5 clear=1 ^D # copy /netbsd /stand modules, etc., etc. umount /mnt
Re: booting from gpt/raid?
m...@netbsd.org wrote: > This guide might be helpful for you > https://wiki.netbsd.org/users/spz/moderndisk/ Thanks!
Re: booting from gpt/raid?
Date:Sun, 1 Jul 2018 23:16:24 -0400 (EDT) From:m...@goathill.org (MLH) Message-ID: <20180702031624.9247212...@chopper.goathill.org> | Thanks. I lost you regarding how to do the 2nd-stage boot. It is no different than if you were doing it on disklabel/mbr partitions (except the device name will be different). | I see that it is wrong, but just for practice... that is what I | have so far: It isn't so wrong really. | (Good thing about gpt partitioning is that it is easily scriptable). Yes. But so are the others, they're just less often used that way instead of interactively. | I did note that if I didn't specify a size, when creating the raid | type partition, if I didn't specify a size, it tried to put it up | front, starting at 34, labelled Unused. If there's no size, gpt just finds the first empty space and uses all of it. If you specify a size, it will find the first big enough empty space. You could also specify the starting block number. | I'm wondering if gpt wants | to put a 2nd-stage bootable raid partition there. No, gpt knows nothing at all about booting, or raid (other than having a partition type "raid", but all gpt knows is the mapping between the name and the numeric value stored in the partition table - which is as much as disklabel knows when you set one of its partitions to raid.) | # gpt create wd2 | # gpt add -b 1024 -l boot_0 -t ffs -s 1g wd2 That is largely doing it the way I suggested, before you could have seen my earlier reply. 1g is a bit big, probably, but not outlandishly so. | # gpt add -s 5243112 -t swap -i 2 wd2 That's fine too (I omitted swap partitions from my earlier list, but you can do it that way.) [You don't normally need to specify -i incidentally.] | # gpt label -i 1 -l swap_0 wd2 I know you know this could have been combined with the previous command. | # gpt biosboot -L boot_0 wd2 That marks it bootable, and installs gptmbr.bin in the PMBR This is for BIOS (legacy) booting. Incidentally, that is what Greg was referring to when he said ... > the 2nd-stage boot, blocks 2-15, are in the partition that is labeled > bootable You got that right, when you did the installboot - that is installing the 2nd stage boot, and you put it on that partition (dk0 as it was configured for you). | # newfs dk0 | # installboot /dev/rdk0 /usr/mdec/bootxx_ffsv2 It would be a good idea to be explicit on the newfs command which FFS version you want it to use, here obviously FFSv2 as that's the boot version you installed. Just add -O2 to the newfs and be certain. | # mount /dev/dk0 /mnt | # cp /usr/mdec/boot /mnt Don't forget a boot.cfg as well (it isn't absolutely required but really is useful to have.) | # gpt add -i 3 -s 7806695847 -l raid_0 -t raid wd2 That's fine. | Does the boot stuff look ok there? Aside from the missing boot.cfg and the question of whether newfs actually made a FFSv2 or not You will probably also want to copy a kernel (/netbsd) to /mnt as well (I don't think /boot knows anything about raid partitions, so it wouldn't be able to find ./netbsd on there). | That brings up the question of whether swap should be type swap or | type raid and make a raid swap partition. That depends what you want to achieve, if you want swap redundancy, so your system will just keep working if a drive dies, then you want swap on raid. But if you'd prefer more swap space with less disk space used and you can tolerate the system perhaps crashing and rebooting if a drive dies (I quite like that, it brings the situation to my attention, I have had situations where a drive has died and I haven't noticed for ages...) But if you decide on raid swap, you might just as well put it on a partition in your big raid filesystem, rather than a separate one, so make a raid, disklabel or set up gpt on that, and then make a swap partition there (along with whatever others you want). You haven't gotten as far as configuring your raid yet in that test run I see... Ans, as in the earlier message, I'd still suggest an EFI partition as well (the unused space from blocks 34..1023 is probably not really big enough, but it might almost work.) kre
Re: booting from gpt/raid?
This guide might be helpful for you https://wiki.netbsd.org/users/spz/moderndisk/
Re: booting from gpt/raid?
Date:Sun, 1 Jul 2018 16:55:05 -0400 (EDT) From:m...@goathill.org (MLH) Message-ID: <20180701205505.af9d712...@chopper.goathill.org> | Things are generally going well but before I actually install a | system, one question I have is how to make the configuration | bootable. The first question to answer is whether you want a BIOS or UEFI boot setup, you can do either with GPT. The firmware in your system might only work with BIOS booting (if it is a bit old) - if it supports UEFI it will probably also allow switching to BIOS boot mode (most do these days,. eventually I'd suspect that firmware makers will drop BIOS support.) | - GPT(8) says to make a bootable partition using gpt but doesn't | mention doing that with raid The raid part really makes no difference, it works the same way for MBR and GPT booting (just different partition setup tools, and so different commands to run.) That said, I have a system configured very much like you describe (it has more, bigger, drives, but that makes no difference) - and what I'd do is make 3 (at least) GPT partitions on each drive (identical sizes). The first should be type EFI probably only needs to be about 10 - 20 MB (yes, megabytes) and will be used for UEFI booting, if you ever set that up. If you are going to use BIOS booting now, you can just leave it empty, otherwise make a FAT filesystem on it (wasting 20MB should not be a concern even if it is never used.) The second partition (on each) should be big enough for a half dozen (or so - depends how many older backup copies you want to keep) netbsd kernels (which can be up to about 8MB each these days. so make it at least 50MB - 128MB would be better - if you want to use modules, rather than just embedding everything, you'll want space for those as well, currently that's about 20MB per kernel version, so that way I'd make this partition about 200MB. This one should be type ffs, and will be the boot parftition - set that one up for booting just the way the NetBSD guide tells you to (regardless of whether you're going to use MBR or UEFI booting). All that should be there is /boot /boot.cfg and as many /netbsd* files as you need (and /stand/*/*/modules if you want them - note only modules to be loaded at boot time are actually needed there, the modules will need to be duplicated on the root filesystem in order to load them after booting, including via module autoload.) Then the third should be whatever space is left (399G and a bit I guess) should have a PT type for NetBSD raid. On that you put either another GPT partition table, or a disklabel, to divide the raid up however you want it partitioned (which can be as just one big chunk if you like - it still should have some kind of label.) Configure the raid with raidctl -A forceroot raidN so it becomes auto configured, and will be the root filesystem (even though you will have booted from the other partition). (softroot might work, that's newer than my setup, so I have never tried it.) Then simply put a complete netbsd installation into the raid partition(s). (root /usr /var /home either all on the one partition, or on partitions of their own, whatever you prefer.) When you boot, the MBR or UEFI boot will load the kernel from the ffs (2nd) GPT partition, when that kernel starts, it will notice the raid partitions (so they do need to be the correct type, in the GPT table, or in the disklabel if using MBR) and also notice that they are to be autoconfigured, so do that, and then move the root filesystem there (the boot partition, where /netbsd came from, will just be forgotten for now.) You can mount the boot partitions (one from each drive) (and the EFI partitions if you are actually using them) if you want (I mostly keep mine unmounted, and mount them only when I want to install a new kernel). When I do that, I typically put the new kernel only on the one that is actually used for booting (the drive the firmware is configured to attempt to boot from first) and leave the other untouched. That way if I somehow botch things, I can always just tell the firmware to swap the order of the boot drives, and the older system just boots. When I am happy it all works, I just rsync the updated boot partition to the other one (essentially mirroring manually). This is usually only needed rarely... This all works, and is easy to configure, and almost impossible to get wrong - the raidframe autoroot mechanism makes almost all of the issues that people otherwise have simply vanish. | - NetBSD Raid guide says to install the bootloader onto one | (preferably both) of the raid units but isn't using gpt on large | disks. Definitely put it all on both, if you don't, the redundancy you get from the raid filesystems will be wasted, as the drive that dies will be the one that you have setup to boot from (the other one will have all of the data just fine, but without a way to boot to get to it). Aside you
Re: booting from gpt/raid?
Greg Troxel wrote: > > m...@goathill.org (MLH) writes: > > > I'm looking at exactly how to set up a couple of 4G disks in a > > I am not really sure, but some advice: > > Generally, the way booting on raid works is that (with a little bit of > fuzz because I amy be off on details) > > it is limited to RAID-1, where therefore each disk is a copy (if you > only read) > > the MBR or first-stage boot is in the normal place for the disk > > the 2nd-stage boot, blocks 2-15, are in the partition that is labeled > bootable > > the bootable partition is of type RAID, and on those, the first 64 > sectors are the raid header (except for 0/mbr, 1/disklabel, and > 2-15/bootxx, so really latter 48 of first 64). Then, the fs that > exists within the RAID-1 starts. > > the 2nd-stage boot code is able to figure out that the boot parttion > is of type raid, not ffs, and then does addr += 64 and tries again. I > am unclear on if it recognizes the raid header, fails to recognize ffs > and tries blindly, or looks at the type. > > therefore, I would expect > >two disks, each gpt >gpt disk-level boot setup normally >with a gpt partition of type raid >in those, bootblocks at front >and included ffs, via raid-1 init >set up to boot the raid parittion as if it were ffs >hope for the best and debug > > to be a reasonable strategy. Thanks. I lost you regarding how to do the 2nd-stage boot. I see that it is wrong, but just for practice... that is what I have so far: (Good thing about gpt partitioning is that it is easily scriptable). I did note that if I didn't specify a size, when creating the raid type partition, if I didn't specify a size, it tried to put it up front, starting at 34, labelled Unused. I'm wondering if gpt wants to put a 2nd-stage bootable raid partition there. # gpt create wd2 dk0 at wd2 (swap_0) deleted # gpt add -b 1024 -l boot_0 -t ffs -s 1g wd2 /dev/rwd2: Partition 1 added: 49f48d5a-b10e-11dc-b99b-0019d1879648 1024 2097152 wd2: GPT GUID: bcbdfa4c-0b35-442c-9813-f3ef257300c0 dk0 at wd2: "boot_0", 2097152 blocks at 1024, type: ffs # gpt add -s 5243112 -t swap -i 2 wd2 /dev/rwd2: Partition 2 added: 49f48d32-b10e-11dc-b99b-0019d1879648 2098176 5243112 dk2 at wd2: "7664738f-158b-45a8-a1bd-0e70d1488604", 5243112 blocks at 2098176, type: swap # gpt label -i 1 -l swap_0 wd2 /dev/rwd2: Partition 1 label changed dk2 at wd2 (7664738f-158b-45a8-a1bd-0e70d1488604) deleted wd2: GPT GUID: bcbdfa4c-0b35-442c-9813-f3ef257300c0 wd2: error 22 adding entry 0 (f6e065e3-5743-4d9b-8fc8-64bbd6c5002d), type 49f48d5a-b10e-11dc-b9 dk2 at wd2: "swap_0", 5243112 blocks at 2098176, type: swap # gpt biosboot -L boot_0 wd2 /dev/rwd2: Partition 1 marked as bootable dk2 at wd2 (7664738f-158b-45a8-a1bd-0e70d1488604) deleted dk0 at wd2 (boot_0) deleted wd2: GPT GUID: bcbdfa4c-0b35-442c-9813-f3ef257300c0 dk0 at wd2: "boot_0", 2097152 blocks at 1024, type: ffs dk2 at wd2: "7664738f-158b-45a8-a1bd-0e70d1488604", 5243112 blocks at 2098176, type: swap # newfs dk0 /dev/rdk0: 1024.0MB (2097152 sectors) block size 16384, fragment size 2048 using 6 cylinder groups of 170.67MB, 10923 blks, 21504 inodes. super-block backups (for fsck_ffs -b #) at: 32, 349568, 699104, 1048640, 1398176, 1747712, # installboot /dev/rdk0 /usr/mdec/bootxx_ffsv2 # mount /dev/dk0 /mnt # cp /usr/mdec/boot /mnt -r--r--r-- 1 root wheel 75832 Jul 1 22:07 boot # gpt add -i 3 -s 7806695847 -l raid_0 -t raid wd2 /dev/rwd2: Partition 3 added: 49f48daa-b10e-11dc-b99b-0019d1879648 34 990 # gpt show -l wd2 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 990 Unused 1024 2097152 1 GPT part - boot_0 2098176 5243112 2 GPT part - swap_0 7341288 7806695847 3 GPT part - raid_0 7814037135 32 Sec GPT table 7814037167 1 Sec GPT header Same for wd3 (except for labels) # gpt show -l wd3 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 990 Unused 1024 2097152 1 GPT part - boot_1 2098176 5243112 2 GPT part - swap_1 7341288 7806695847 3 GPT part - raid_1 7814037135 32 Sec GPT table 7814037167 1 Sec GPT header Does the boot stuff look ok there? That brings up the question of whether swap should be type swap or type raid and make a raid swap partition.
Re: booting from gpt/raid?
m...@goathill.org (MLH) writes: > I'm looking at exactly how to set up a couple of 4G disks in a > bootable gpt/raid1 (raidframe, BIOS boot) configuration. I have a > temporary 80G boot drive I'm currently working from. It is currently > running NetBSD 8.99.17 > > I am attempting to follw the instrucitons in GPT(8), > https://www.netbsd.org/docs/guide/en/chap-rf.html#chap-rf-intro > https://wiki.netbsd.org/users/mlelstv/using-large-disks/#index6h1 > > Things are generally going well but before I actually install a > system, one question I have is how to make the configuration > bootable. > > - GPT(8) says to make a bootable partition using gpt but doesn't > mention doing that with raid > > - NetBSD Raid guide says to install the bootloader onto one > (preferably both) of the raid units but isn't using gpt on large > disks. I am not really sure, but some advice: Generally, the way booting on raid works is that (with a little bit of fuzz because I amy be off on details) it is limited to RAID-1, where therefore each disk is a copy (if you only read) the MBR or first-stage boot is in the normal place for the disk the 2nd-stage boot, blocks 2-15, are in the partition that is labeled bootable the bootable partition is of type RAID, and on those, the first 64 sectors are the raid header (except for 0/mbr, 1/disklabel, and 2-15/bootxx, so really latter 48 of first 64). Then, the fs that exists within the RAID-1 starts. the 2nd-stage boot code is able to figure out that the boot parttion is of type raid, not ffs, and then does addr += 64 and tries again. I am unclear on if it recognizes the raid header, fails to recognize ffs and tries blindly, or looks at the type. therefore, I would expect two disks, each gpt gpt disk-level boot setup normally with a gpt partition of type raid in those, bootblocks at front and included ffs, via raid-1 init set up to boot the raid parittion as if it were ffs hope for the best and debug to be a reasonable strategy. signature.asc Description: PGP signature
Re: booting from gpt/raid?
> I'm looking at exactly how to set up a couple of 4G disks in a > bootable gpt/raid1 (raidframe, BIOS boot) configuration. I have a Ug. I mean 4000G
booting from gpt/raid?
I'm looking at exactly how to set up a couple of 4G disks in a bootable gpt/raid1 (raidframe, BIOS boot) configuration. I have a temporary 80G boot drive I'm currently working from. It is currently running NetBSD 8.99.17 I am attempting to follw the instrucitons in GPT(8), https://www.netbsd.org/docs/guide/en/chap-rf.html#chap-rf-intro https://wiki.netbsd.org/users/mlelstv/using-large-disks/#index6h1 Things are generally going well but before I actually install a system, one question I have is how to make the configuration bootable. - GPT(8) says to make a bootable partition using gpt but doesn't mention doing that with raid - NetBSD Raid guide says to install the bootloader onto one (preferably both) of the raid units but isn't using gpt on large disks. using-large-disks apparently uses a separate boot drive As I would prefer to not use a separate boot drive, what is the better way to get the system to boot? Thanks
