bsdinstall-amd64-20110313 remarks
Hi, yesterday I tested the images listed in the subject and have the following remarks: - At least the memstick image contains an empty fstab - Does the usage of a dangerously dedikated disklabel give any advantage? - The usage of an UFS-Label for root mounting should be more flexible - The first dialog step should set the keyboard layout - The /etc is not writable which would greatly reduce the usefulness for the ISO image (no modified resolv.conf, sshd_config, ...) The usage of a nanobsd based base-installation would give a sufficient advanced Live-OS installation. You could take a look into src/tools/tools/nanobsd/rescue where I tried to address most of the issues above primary for rescuing GPT/ZFS installations (with still hardcoded keyboard though). With two nanobsd slices on one memstick you can actually produce combined i386/and64 Live-OS memsticks... I get both on a 2GiB memstick (Without packages). What do you think? Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall-amd64-20110313 remarks
On Mon, 21 Mar 2011, Lars Engels wrote: Date: Mon, 21 Mar 2011 11:04:28 +0100 From: Lars Engels lars.eng...@0x20.net To: Michael Reifenberger m...@reifenberger.com Cc: Nathan Whitehorn nwhiteh...@freebsd.org, FreeBSD-Current curr...@freebsd.org Subject: Re: bsdinstall-amd64-20110313 remarks On Mon, Mar 21, 2011 at 09:25:36AM +0100, Michael Reifenberger wrote: Hi, yesterday I tested the images listed in the subject and have the following remarks: - At least the memstick image contains an empty fstab - Does the usage of a dangerously dedikated disklabel give any advantage? - The usage of an UFS-Label for root mounting should be more flexible - UFS-labeling does not work I let bsdinstall partition the disk automatically and edited the proposed partitions to add labels, but after the first boot, neither fstab nor /dev/label showed any labels. I did not mean to use UFS-Labels for the bsdinstall partitioner. I meant the use of UFS-Labels for the memstick image itself. BTW: The UFS labels should show up under /dev/ufs/... The cd9660 labels should show up under /dev/cd9660/... Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall-amd64-20110313 remarks
On Mon, Mar 21, 2011 at 09:25:36AM +0100, Michael Reifenberger wrote: Hi, yesterday I tested the images listed in the subject and have the following remarks: - At least the memstick image contains an empty fstab - Does the usage of a dangerously dedikated disklabel give any advantage? - The usage of an UFS-Label for root mounting should be more flexible - UFS-labeling does not work I let bsdinstall partition the disk automatically and edited the proposed partitions to add labels, but after the first boot, neither fstab nor /dev/label showed any labels. pgpQbGAc72hSY.pgp Description: PGP signature
Re: bsdinstall-amd64-20110313 remarks
On 03/21/11 03:25, Michael Reifenberger wrote: Hi, yesterday I tested the images listed in the subject and have the following remarks: - At least the memstick image contains an empty fstab The memstick stuff is new and (mostly) untested, so I'll check that out. - Does the usage of a dangerously dedikated disklabel give any advantage? Not that I can think of -- I'm not sure about maximum disk sizes for pure BSD-label disks. It's a legitimate option, though, for people doing manual configuration. - The usage of an UFS-Label for root mounting should be more flexible Yes. It is somewhat difficult however, to cross-correlate gpart labels for GPT, APM, and PC98, with the labeled provider names (the label is not UFS labels, but gpart ones). - The first dialog step should set the keyboard layout That *is* the first step. - The /etc is not writable which would greatly reduce the usefulness for the ISO image (no modified resolv.conf, sshd_config, ...) This is only partly true. /etc/resolv.conf is a symlink into /tmp, which allows DHCP and network configuration to work. The usage of a nanobsd based base-installation would give a sufficient advanced Live-OS installation. You could take a look into src/tools/tools/nanobsd/rescue where I tried to address most of the issues above primary for rescuing GPT/ZFS installations (with still hardcoded keyboard though). With two nanobsd slices on one memstick you can actually produce combined i386/and64 Live-OS memsticks... I get both on a 2GiB memstick (Without packages). What do you think? That's interesting, and I'll take a look around what you've done there when I get some spare time. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall-amd64-20110313 remarks
On 03/21/11 05:04, Lars Engels wrote: On Mon, Mar 21, 2011 at 09:25:36AM +0100, Michael Reifenberger wrote: Hi, yesterday I tested the images listed in the subject and have the following remarks: - At least the memstick image contains an empty fstab - Does the usage of a dangerously dedikated disklabel give any advantage? - The usage of an UFS-Label for root mounting should be more flexible - UFS-labeling does not work I let bsdinstall partition the disk automatically and edited the proposed partitions to add labels, but after the first boot, neither fstab nor /dev/label showed any labels. The labels are gpart labels, so they show up, e.g., under /dev/gpt. They aren't currently used to set up fstab, as it is somewhat difficult to predict their path. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall-amd64-20110313 remarks
On Mon, 21 Mar 2011, Nathan Whitehorn wrote: ... - Does the usage of a dangerously dedikated disklabel give any advantage? Not that I can think of -- I'm not sure about maximum disk sizes for pure BSD-label disks. It's a legitimate option, though, for people doing manual configuration. The question was only ment for the use of dangerously dedikated disklabel by the memstick itself. I have no opinion for use by the patitioner. - The usage of an UFS-Label for root mounting should be more flexible Yes. It is somewhat difficult however, to cross-correlate gpart labels for GPT, APM, and PC98, with the labeled provider names (the label is not UFS labels, but gpart ones). ditto. - The first dialog step should set the keyboard layout That *is* the first step. Inside the bsdinstaller, yes. The very first dialog step is the welcome page. Inside Shell or Live CD youl'll not get asked. - The /etc is not writable which would greatly reduce the usefulness for the ISO image (no modified resolv.conf, sshd_config, ...) This is only partly true. /etc/resolv.conf is a symlink into /tmp, which allows DHCP and network configuration to work. I still prefer a standard /etc with writable entries. Less special and more POLA. Thanks for your work on bsdinstaller anyhow! Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
