Re: 7.2-stable upgrade changes disknames

From: Willem Jan Withagen <wjw_at_withagen.nl>
Date: Mon, 29 Jun 2009 17:27:29 +0200
Aisaka Taiga wrote:
> Willem Jan Withagen wrote:
>> On 7.2 this used to work(tm), on 8.0 boot start complaining.
>> So somewhere a (unwanted) flexibility got deleted
>> And I have to manually fix my /etc/fstab to what is factual correct.
>> And that was what my message was about:
>>     It can/will(??) bite a lot more users.
>> With similar remarks and/or questions.
> To be honest, I'm quite amused that it actually worked for you, because 
> if you use a dangerously dedicated disk you, basically, don't need a 
> partition table at all as the slice 'table' (bsdlabel) takes care of 
> everything. And if there's no partition table, there can be no adXs1a 
> boot device - even in 7.2.
> If you got your fstab from sysinstall, I don't really know how did you 
> manage to migrate to a DDD without modifying fstab, because sysinstall 
> has no clue about the existence of DDDs. To get a system running on a 
> DDD you would basically need to install BTX (using fdisk), label the 
> drive with bsdlabel, and then dump/restore or tar c | tar x the 
> filesystems.
> But according to you, until -CURRENT you had a working partition table 
> (hence adXs1a working). And make installworld should never bother with 
> partition tables.
> (This is really weird.)

Although I'm know to always choose the options that will trigger edge 
cases. This was a fast en no-brainer install, hence a DDD install.

So now the question boils down to: how many people did install DDD and 
were abusing the feature that it also mimiced a sliced disk??
Those are the users that are going to run into a non-booting upgrade.
So how many users use a DDD install?

And the second question:
	Does this warrant at least a notification in the UPGRADING file?

 From dimitry's answer I understand that it really used to function as a 
I described, and that it was more incidental that things worked the way 
sysinstall left them after booting.

--WjW
Received on Mon Jun 29 2009 - 13:27:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:50 UTC