svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Warner Losh]

Now that the horse is out of the barn, the following might be a little late (unless we unpull the trigger for a month).

But what if we warned that / was on a device name, and not on a 'named' device.  Complain if it was on /dev/da0, but not if it was on /dev/ufs/fred-root.

Users would see this warning and react.

Next best thing: make installkernel check for devices on /dev/adX and refuse to install the kernel if they are (unless REALLY_THIS_IS_RIGHT is defined :).

This won't help the binary upgrader, but will prevent massive footshooting in the mean time.

Warner

On Apr 24, 2011, at 1:41 PM, Alexander Motin wrote:

> On 24.04.2011 21:59, Bjoern A. Zeeb wrote:
>>> What's about creating some kind of symlinks, it could be nice if it
>>> worked, but I don't see the way to do it on disk(9) or GEOM layers
>>> without breaking device's access counters and as result further random
>>> problems.
>> 
>> I had been pondering devfs "link"s myself, the problem is that from the rc
>> framework they come too late.  If you can add a simple .ko that does it
>> programmatically on 9 that would be great.  The problem is that after booting
>> the new kernel you don't know whether people had ATA_STATIC on or not, so
>> we'd have to go with the defaults, that were in 8.x (and an extra tunable to
>> flip the logic maybe)?
> 
> Devfs links won't help users with hardcoded provider names in gmirror, etc -- from GEOM PoV there will be no such providers. Also to create proper mapping that module should have real-time information from CAM about ATA controller details. And looking that it will have to link in real time any derivative providers also (ad4s1a -> ada0s1a) I worry if it is possible at all. Some devfs expert needed here.
> 
>>> Looking now on these "do or revert" demands to keep old device naming,
>>> I'll try to make some hacks to CAM and ada(4) driver to mimic old "adX"
>>> names. I see it in form of some loader tunable, disabled by default (as
>>> it should be on newly installed systems), but that could be set prior to
>>> upgrade if user doesn't want to bother with device names at that moment.
>>> It should partially hide problem for some time.
>> 
>> It would need to be in and on by default for the lifetime of 9 as it's not
>> in the last 8.x release (which would need it the other way round anyway.
>> MIght it be a good idea to do that as well afterwards providing ada links
>> on the next 8.x release?).
> 
> I wouldn't like to keep that ugly numbering on by default till the 9.x EoL even for new installations. Also remember about number of people already using new ATA, for whom requirement to disable that tunable may also be uncomfortable.
> 
>> The user could disable it after the conversion happened though with a tunable
>> to get rid of the extra /dev/* noise.  We could even check for it being on
>> and check fstab and warn/pester the user then that he'll need to migrate
>> (on boot from rc.d, in weekly mails, ...).
> 
> It would be fine if it was just devfs noise, but I have some doubts about it (above).
> 
>> If we have both information available (old from the kernel transition code)
>> and new we could even provide a script to do it.
>> 
>> The reason we might not want to do it automatically is that if the user will
>> decide to boot kernel.old because the new kernel panics after 2 days, she'll
>> be facing the new ada entries in fstab with an 8.x kernel and that would not
>> work either.   So it's a decision users need to make eventually themselves
>> during the lifetime of 9.x when upgrading from an older release.
> 
> Reasonable.
> 
>>> Will such solution be acceptable?
>> 
>> I think any solution will be acceptable if it (mostly) works and gets the
>> possible fallout rate (significantly) down and thanks a lot for picking it
>> up now!
> 
> But that solution should not include setting tunables before upgrading? Can't we teach mergemaster or whatever else to set it depending on whet disks are now present in system?
> 
>> PS: And I think you'll find a lot of testers the next days/weeks on current@
>> when people update their kernels and forgot to read UPDATING or fail to
>> do the conversion properly.;)
> 
> I can always say: "read UPDATING" (for log: I am not completely serious here. :)).
> 
> -- 
> Alexander Motin
> 
>