Re: Should newfs include -S 4096? was Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
On Fri, 23 Nov 2012, free...@johnea.net wrote: One of the complications was getting old metadata off of the drive. After trying a couple of 'dd' invocations: # overwriting the first sector dd if=/dev/zero of=/dev/ada0 bs=512 count=1 # also tried overwriting the last sector diskinfo ada0 | cut -f4 3907029168 (subtract 34, per WB) (I actually just subtracted the trailing 68) dd if=/dev/zero of=/dev/ada0 seek=3907029100 This would still seem to not delete all of the metadata, since after issuing: gmirror label -b split gm0 /dev/ada0 gmirror load # repartition new mirror gpart create -s MBR mirror/gm0 # ignore mirror/gm0s1 added, but partition is not aligned on 4096 bytes after add gpart add -t freebsd -a 4k mirror/gm0 # create the bsdlabel partitions in slice 1 (s1) gpart create -s BSD mirror/gm0s1 I would see that the old gm0s1a and gm0s1b had reappeared, even though I had not yet issued the 'add -t freebsd-ufs'. I'm not sure if they came back with the 'add -t freebsd' or the 'create -s BSD'. Saved this since yesterday, thinking maybe I could come up with an idea, but so far I can't think what would cause that. It might not hurt to force a retaste after the dd. The only thing that seemed to fix it was: gpart destroy -F /dev/ada0 I also tried at one point: gpart destroy -F ada0 gpart create -s gpt ada0 gpart destroy -F ada0 The thing I wonder about now: Should newfs include -S 4096? I used: newfs -U /dev/mirror/gm0s1a Will this lead to 512 byte sector access to the disk through the file system? Will this impact performance or longevity of the mirror? It's a good question; I have not tried it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Should newfs include -S 4096? was Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
On 2012-11-20 21:10, Warren Block wrote: On Tue, 20 Nov 2012, free...@johnea.net wrote: On 2012-11-20 14:28, Gary Aitken wrote: On 11/20/12 13:34, free...@johnea.net wrote: freebsd-update upgrade -r 9.1-RC3 ... Not UFS No ada0 No boot Seems like it isn't supposed to work for 9.1-RC2 I previously used binary update to migrate from 9.0 to 9.1, via: freebsd-update upgrade -r 9.1-RC1 freebsd-update install reboot freebsd-update install reboot I'm starting to think having the swap partition in gm0s1a and the booting UFS partition in ada0s1b is the problem: http://forums.freebsd.org/showthread.php?t=31954 The Not UFS error comes immediately on boot. If I boot from rescue media, I can start the gmirror, mount it and chroot into it. The whole install seems fine except for the first stage boot loader finding the UFS partition. A handy bootloader config trick would be greatly appreciated! boot(8) says The automatic boot will attempt to load /boot/loader from partition `a' of either the floppy or the hard disk. You could try setting the correct device path in /boot/boot.config, but I suspect that won't be read until too late. gptboot looks for the first UFS partition. Maybe /boot/boot can be modified to do that also. I ended up booting from rescue media, removing one drive and stopping the gmirror, creating a new gmirror on the removed drive to place the UFS partition first, and performing a dump/restore to transfer the system. Then I was able to boot from the new gmitrror and add the second drive to it. One of the complications was getting old metadata off of the drive. After trying a couple of 'dd' invocations: # overwriting the first sector dd if=/dev/zero of=/dev/ada0 bs=512 count=1 # also tried overwriting the last sector diskinfo ada0 | cut -f4 3907029168 (subtract 34, per WB) (I actually just subtracted the trailing 68) dd if=/dev/zero of=/dev/ada0 seek=3907029100 This would still seem to not delete all of the metadata, since after issuing: gmirror label -b split gm0 /dev/ada0 gmirror load # repartition new mirror gpart create -s MBR mirror/gm0 # ignore mirror/gm0s1 added, but partition is not aligned on 4096 bytes after add gpart add -t freebsd -a 4k mirror/gm0 # create the bsdlabel partitions in slice 1 (s1) gpart create -s BSD mirror/gm0s1 I would see that the old gm0s1a and gm0s1b had reappeared, even though I had not yet issued the 'add -t freebsd-ufs'. I'm not sure if they came back with the 'add -t freebsd' or the 'create -s BSD'. The only thing that seemed to fix it was: gpart destroy -F /dev/ada0 I also tried at one point: gpart destroy -F ada0 gpart create -s gpt ada0 gpart destroy -F ada0 After that I could create the new partitions within the slice, with freebsd-ufs first: # size of ufs partition must be calculated, from 'diskinfo -v /dev/ada0': 2000398934016 # media size in bytes (1.8T) ; 1024*1024*1024 1073741824 ; 2000398934016/1073741824 1863.01668548583984375 # subtract 8G from 1863 = 1855G gpart add -t freebsd-ufs -a 4k -s 1855G mirror/gm0s1 gpart add -t freebsd-swap -a 4k mirror/gm0s1 Everything looks good with 4K alignment, and freebsd-ufs first: gpart show =63 3907029104 mirror/gm0 MBR (1.8T) 63 63 - free - (31k) 126 3907028979 1 freebsd [active] (1.8T) 3907029105 62 - free - (31k) = 0 3907028979 mirror/gm0s1 BSD (1.8T) 0 2- free - (1.0k) 2 3890216960 1 freebsd-ufs (1.8T) 389021696216812016 2 freebsd-swap (8.0G) 3907028978 1- free - (512B) After newfs, I was able to dump/restore to transfer the installed system from ada1 to gm0 (which is 9.1-RC3 now). The thing I wonder about now: Should newfs include -S 4096? I used: newfs -U /dev/mirror/gm0s1a Will this lead to 512 byte sector access to the disk through the file system? Will this impact performance or longevity of the mirror? Thanks again for the sage advice! johnea ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
gpt booting (Was: Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3)
On 11/21/12 05:11, Warren Block wrote: gptboot looks for the first UFS partition. Maybe /boot/boot can be modified to do that also. It's a little more complicated than that Warren. AIUI gptboot first looks (in partition order) for partitions with both the bootme and bootonce attributes set. If it doesn't find any, or if they all failed to boot it then tries booting partitions with just the bootme attribute. It only boots the first UFS partition if no partitions have the bootme attribute set, and IIRC that is for compatibility with the 8.x gptboot which didn't know the boot* attributes. Confusingly, there's no manual page for gptboot to document this. It's sort of implicit in the gpart manual page, in the section on ATTRIBUTES for GPT, but the best way to understand it is to read the code for gptfind in /usr/src/sys/boot/common/gpt.c ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: gpt booting (Was: Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3)
On Wed, 21 Nov 2012, Arthur Chance wrote: On 11/21/12 05:11, Warren Block wrote: gptboot looks for the first UFS partition. Maybe /boot/boot can be modified to do that also. It's a little more complicated than that Warren. AIUI gptboot first looks (in partition order) for partitions with both the bootme and bootonce attributes set. If it doesn't find any, or if they all failed to boot it then tries booting partitions with just the bootme attribute. It only boots the first UFS partition if no partitions have the bootme attribute set, and IIRC that is for compatibility with the 8.x gptboot which didn't know the boot* attributes. Confusingly, there's no manual page for gptboot to document this. It's sort of implicit in the gpart manual page, in the section on ATTRIBUTES for GPT, but the best way to understand it is to read the code for gptfind in /usr/src/sys/boot/common/gpt.c Well, yes. The point is that gptboot doesn't just assume that p2, say, is where the bootable UFS partition must be. I've also noted the lack of a gptboot man page, and it's on my long list of Things That Should Be Done. There was a thread on -doc: http://lists.freebsd.org/pipermail/freebsd-doc/2012-June/020060.html Help would be greatly appreciated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
Hello, I recently installed a 9.1-RC2 system using gmirror with MBR, and swap in first bsdlabel. orsbackup# gpart show =63 3907029104 mirror/gm0 MBR (1.8T) 63 63 - free - (31k) 126 3907028979 1 freebsd [active] (1.8T) 3907029105 62 - free - (31k) = 0 3907028979 mirror/gm0s1 BSD (1.8T) 0 2- free - (1.0k) 216777216 1 freebsd-swap (8.0G) 16777218 3890251760 2 freebsd-ufs (1.8T) 3907028978 1- free - (512B) The drive was setup with the following commands: orsbackup# gpart create -s MBR mirror/gm0 mirror/gm0 created orsbackup# gpart add -t freebsd -a 4k mirror/gm0 # ignored mirror/gm0s1 added, but partition is not aligned on 4096 bytes # create the bsdlabel partitions in slice 1 (s1) orsbackup# gpart create -s BSD mirror/gm0s1 orsbackup# gpart add -t freebsd-swap -a 4k -s 8g mirror/gm0s1 orsbackup# gpart add -t freebsd-ufs -a 4k mirror/gm0s1 # put bootcode on the MBR and mark the first slice active orsbackup# gpart bootcode -b /boot/mbr mirror/gm0 orsbackup# gpart set -a active -i 1 mirror/gm0 # put bootcode on the bsdlabel orsbackup# gpart bootcode -b /boot/boot mirror/gm0s1 The system rebooted several times without issue. This system is a testbed for 9.1 and is not yet deployed as a production server. I thought I'd update to 9.1-RC3, so I ran: freebsd-update upgrade -r 9.1-RC3 freebsd-update install reboot The system won't boot and complains about: Not UFS No ada0 No boot Before I charge ahead with reissuing the gpart bootcode commands I thought I'd: a) make others aware there may be issues in freebsd-update with the 9.1 release candidates b) ask about the best way to resolve this bootloader issue. Thanks you for any pointers in resolving this bootloader issue! johnea ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
On 11/20/12 13:34, free...@johnea.net wrote: Hello, I recently installed a 9.1-RC2 system using gmirror with MBR, and swap in first bsdlabel. orsbackup# gpart show =63 3907029104 mirror/gm0 MBR (1.8T) 63 63 - free - (31k) 126 3907028979 1 freebsd [active] (1.8T) 3907029105 62 - free - (31k) = 0 3907028979 mirror/gm0s1 BSD (1.8T) 0 2- free - (1.0k) 216777216 1 freebsd-swap (8.0G) 16777218 3890251760 2 freebsd-ufs (1.8T) 3907028978 1- free - (512B) The drive was setup with the following commands: orsbackup# gpart create -s MBR mirror/gm0 mirror/gm0 created orsbackup# gpart add -t freebsd -a 4k mirror/gm0 # ignored mirror/gm0s1 added, but partition is not aligned on 4096 bytes # create the bsdlabel partitions in slice 1 (s1) orsbackup# gpart create -s BSD mirror/gm0s1 orsbackup# gpart add -t freebsd-swap -a 4k -s 8g mirror/gm0s1 orsbackup# gpart add -t freebsd-ufs -a 4k mirror/gm0s1 # put bootcode on the MBR and mark the first slice active orsbackup# gpart bootcode -b /boot/mbr mirror/gm0 orsbackup# gpart set -a active -i 1 mirror/gm0 # put bootcode on the bsdlabel orsbackup# gpart bootcode -b /boot/boot mirror/gm0s1 The system rebooted several times without issue. This system is a testbed for 9.1 and is not yet deployed as a production server. I thought I'd update to 9.1-RC3, so I ran: freebsd-update upgrade -r 9.1-RC3 freebsd-update install reboot The system won't boot and complains about: Not UFS No ada0 No boot Before I charge ahead with reissuing the gpart bootcode commands I thought I'd: a) make others aware there may be issues in freebsd-update with the 9.1 release candidates b) ask about the best way to resolve this bootloader issue. Thanks you for any pointers in resolving this bootloader issue! johnea Not sure, but this might apply: The freebsd-update tool is used to fetch, install, and rollback binary updates to the FreeBSD base system. Note that updates are only available if they are being built for the FreeBSD release and architecture being used; in particular, the FreeBSD Security Team only builds updates for releases shipped in binary form by the FreeBSD Release Engineering Team, e.g., FreeBSD 7.3-RELEASE and FreeBSD 8.0-RELEASE, but not FreeBSD 6.3-STABLE or FreeBSD 9.0-CURRENT. Seems like it isn't supposed to work for 9.1-RC2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
On 2012-11-20 14:28, Gary Aitken wrote: On 11/20/12 13:34, free...@johnea.net wrote: freebsd-update upgrade -r 9.1-RC3 ... Not UFS No ada0 No boot Seems like it isn't supposed to work for 9.1-RC2 I previously used binary update to migrate from 9.0 to 9.1, via: freebsd-update upgrade -r 9.1-RC1 freebsd-update install reboot freebsd-update install reboot I'm starting to think having the swap partition in gm0s1a and the booting UFS partition in ada0s1b is the problem: http://forums.freebsd.org/showthread.php?t=31954 The Not UFS error comes immediately on boot. If I boot from rescue media, I can start the gmirror, mount it and chroot into it. The whole install seems fine except for the first stage boot loader finding the UFS partition. A handy bootloader config trick would be greatly appreciated! johnea ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
On Tue, 20 Nov 2012, free...@johnea.net wrote: On 2012-11-20 14:28, Gary Aitken wrote: On 11/20/12 13:34, free...@johnea.net wrote: freebsd-update upgrade -r 9.1-RC3 ... Not UFS No ada0 No boot Seems like it isn't supposed to work for 9.1-RC2 I previously used binary update to migrate from 9.0 to 9.1, via: freebsd-update upgrade -r 9.1-RC1 freebsd-update install reboot freebsd-update install reboot I'm starting to think having the swap partition in gm0s1a and the booting UFS partition in ada0s1b is the problem: http://forums.freebsd.org/showthread.php?t=31954 The Not UFS error comes immediately on boot. If I boot from rescue media, I can start the gmirror, mount it and chroot into it. The whole install seems fine except for the first stage boot loader finding the UFS partition. A handy bootloader config trick would be greatly appreciated! boot(8) says The automatic boot will attempt to load /boot/loader from partition `a' of either the floppy or the hard disk. You could try setting the correct device path in /boot/boot.config, but I suspect that won't be read until too late. gptboot looks for the first UFS partition. Maybe /boot/boot can be modified to do that also. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
