Re: may I suggest two new symlinks: newfs_ufs for newfs and newfs_hammer1 for newfs_hammer ?
On Wed, 12 Aug 2020 16:08:58 -0900 Matthew Dillon wrote: > For now I'd rather not. It would certainly be less ambiguous but there is > a lot of history there and, again, potential backwards portability issues. ACK > One thing that would be nice would be for 'newfs' to look at the filesystem > type in the disklabel for the specified device (if possible) and exec the > correct newfs_* program based on that type. Another big problem, though, > is that the options and other arguments are different for each newfs_* > variant. You're right. > -Matt Thanks for your replies considering my suggestions :)
Re: suggestion: what about restoring the disklabel from stdin instead of a given file (if not specified) ?
On Wed, 12 Aug 2020 16:05:42 -0900
Matthew Dillon wrote:
> There is nothing particularly onerous in the code that would prevent it,
> but I would still require that an argument be specified. Something like
> "-" is typically indicative of stdin. If someone wanted to submit a patch
> to use stdin for the protofile in that situation then sure.
ACK
> However, generally speaking, I would not recommend doing this because it
> creates a situation where you, or others, write scripts expecting that
> disklabel -R can take input from stdin and these scripts would then not
> work properly on older systems. So even though it may seem a little
> annoying to generate a temporary file, that's going to be the most portable
> method to use whether we add the stdin option or not.
I must admit I didn't think a little on backward compatibility issues.
Creating a temporary file may not be "elegant" to me but if it works (and it
is working fine) leave it as it is. After all that's what really matter. Your
advice is what really counts on the end.
Sorry to choke up this list a bit lately. Besides some issues I encountered
attempting to run it on my hardware I do really want to use this OS daily,
and I am doing my best to learn it. Please, spare me any dumb question but do
not hesitate to state that this or that is a dumb question or go read the
manuals first. I assure you I will never take offense for such replies, they
are part of the learning process.
By the way, I need to say you I have a LOT of respect for your work.
And its sincere :)
> -Matt
>
> On Tue, Aug 11, 2020 at 5:26 PM nacho Lariguet wrote:
>
> > This is only a minor suggestion:
> >
> > echo "${strPartitionLayout}" | /sbin/disklabel64 -R -r -B
> > "/dev/whatever/'; ### what about restoring the slice label from stdin
> > instead of a temp file (if not specified) ?
> >
> > This way we can avoid to:
> >
> > - create a temporary file to hold the (edited) partition layout
> > - add the partition layout example produced by default by disklabel after
> > creating the label itself to the temporary file
> > - cut the partition layout example
> > - add the partition layout as needed (the real one)
> > - run disklabel64 -R to import the temporary file to modify the real label
> > on the drive
> > - delete the temporary file
> >
> > I think building the label in a string variable and then passing it to
> > disklabel64 will be a far more elegant solution.
> >
> > A practical example (actually an excerpt for my ongoing installation
> > script):
> >
> > #!/bin/csh -f
> >
> > if ( ! -l '/sbin/newfs_ufs' ) then
> >
> >/bin/ln -s /sbin/newfs /sbin/newfs_ufs; ### allow me this for a while :)
> >
> > endif ;
> >
> > set strDriveName = 'Intel-SSD-180-GB'; ### whatever you want: for file
> > name purposes only (mainly to report on the drive status)
> > set strDriveSN = 'CVCV2034019Y180EGN'; ### to find the right drive use:
> > /bin/ls -l /dev/da*;
> > set strDriveSNdevice = "/dev/serno/${strDriveSN}";
> > set strDrive = 'da0'; ### improvements: should be automatically set from
> > given SN
> > set strDriveSlice0 = "${strDrive}s0"; ### intended to hold the ESP slice
> > set strDriveSlice1 = "${strDrive}s1"; ### intended to hold the BSD slice
> > set strDriveSlice1Partitions = ( \
> >'a: 1G 0 4.2BSD ###_ie:_boot_volume' \
> >'d: 32G * HAMMER2 ###_ie:_system_volume' \
> >'e: 16G * HAMMER2 ###_ie:_build_volume' \
> >'f: 128G * HAMMER2 ###_ie:_data_volume' \
> >); ### please: use underscore instead of spaces for comments; otherwise
> > they will be translated to TABs
> > set strDriveSlice1FileSystems = ( \
> >"ufs -i '65536' -L 'boot' '${strDriveSNdevice}.s1a';" \
> >"hammer2-L 'system' '${strDriveSNdevice}.s1d';" \
> >"hammer2-L 'build' '${strDriveSNdevice}.s1e';" \
> >"hammer2-L 'data' '${strDriveSNdevice}.s1f';" \
> >); ### ie: the file-systems to be created on each of the above
> > partitions (for HAMMER#2 use -f only if size ≤ 10 GB)
> >
> > set strDriveSlice1DL = './whatever'; ### the temporary file in question
> >
> > set bolGOdriveFormatBSD = (0);
> >
> > if ( $bolGOdriveFormatBSD == (1) ) then ### 2.2 formatting the BSD
> > partition for the boot, system, and any other volumes:
> >
> >/usr/bin/printf "formatting the BSD partition for the boot, system, and
> > any other volumes on /dev/${strDriveSlice1}:\n\n";
> >
> >### enabling disklabel writing:
> >
> >/sbin/disklabel64 -W "/dev/${strDriveSlice1}";
> >
> >### cleaning-up and labeling the BSD slice:
> >
> >/bin/dd if=/dev/zero of="/dev/${strDriveSlice1}" bs='32K' count='16';
> >
> >/sbin/disklabel64 -w -r -B "/dev/${strDriveSlice1}" 'auto' 'BSD'; ###
> > creates a slice label (also writing bootstrap code)
> >
> >### editing/restoring current slice label for a custom partition layout:
> >
> >/sbin/disklabel64 -r "/dev/${strDriveSlice1}" > "${strDriveSlice1DL}";
> > ### outputs current slice
Re: may I suggest two new symlinks: newfs_ufs for newfs and newfs_hammer1 for newfs_hammer ?
For now I'd rather not. It would certainly be less ambiguous but there is a lot of history there and, again, potential backwards portability issues. One thing that would be nice would be for 'newfs' to look at the filesystem type in the disklabel for the specified device (if possible) and exec the correct newfs_* program based on that type. Another big problem, though, is that the options and other arguments are different for each newfs_* variant. -Matt
Re: can I use the display native resolution on vty0 as on any other vty's using KMS ?
Hello As discussed earlier, the difference between ttyv0 vs others is almost expected pre-drm. I don't know the syscons code, there might be other details in play as well and that could be the reason why the algorithm described earlier does not work out for you. Actually, I tested another machine with UEFI and a 4K screen, it gives 80x32, which is not the expected result using the algorithm. So pre-drm, it may work (eg on my laptop) or it may not work (on the desktop). However, with drm/radeon/i915 kldloaded, the difference should go away. That seems unexpected to me. This said, my laptop shows a difference between cold boot and warm boot. When I cold boot the laptop and kldload i915, it won't attach or initialize properly; I'm not sure what is happening. I have to reboot (with power on), then everything works fine; i915 initializes properly. Maybe something like this is in play with your machine as well? You should see the attach etc drm messages in /var/log/messages if everything is OK. With UEFI I don't know if there is a utility to change the video mode. The vidcontrol modes are for VGA, it does not work with UEFI. The sysctl man says: --- Some of the variables which cannot be modified during normal system operation can be initialized via loader(8) tunables. This can for example be done by setting them in loader.conf(5). Please refer to loader.conf(5) for more information on which tunables are available and how to set them. --- Cheers Peeter -- On Tue, Aug 11, 2020 at 9:49 PM nacho Lariguet wrote: > > On Tue, 11 Aug 2020 15:26:38 -0300 > nacho Lariguet wrote: > > This is a follow up: > > If, instead of, trying to do: [sysctl kern.kms_columns=-1;] post boot > I do [set kern.kms_columns=-1] in the boot loader options ONLY, I mean > without initializing the DRM drivers there, I still end up with ttyv0 > @ 80x25 while all the other ttyv>=1 are @ 240x75 :( > > > On Tue, 11 Aug 2020 11:18:34 +0300 > > "karu.pruun" wrote: > > > > > Hello > > > > > > > Is it possible right now to end up in a pre-DRM situation by default ? > > > > IIRC kern.kms_console now defaults to 1 (don't know since when it does). > > > > > > The terminology here is a little confusing. I used pre-drm to mean > > > "until a drm driver (i915 or radeon) is loaded". Let me try to clarify > > > booting. > > > > OK. Now it is crystal-clear what pre-DRM is. My guess was pre-DRM meaned > > before we (I mean dragonFly) started using kms_console by default. > > > > > The first screen with the boot menu is displayed by the loader. The > > > kernel modules to load by the loader are given in > > > > > > /boot/loader.conf > > > > Right. The only thing I always added there is kern.kms_columns=-1 > > > > > However, the official advice is that the loader load the absolute > > > required minimum of kernel modules. For instance, my loader.conf has > > > no modules. This is because memory is tight at that early stage. If > > > you include, e.g. a drm driver, i915 or radeon, then the kernel will > > > most likely crash at boot. > > > > > > The official advice is to load modules later by placing them in > > > /etc/rc.conf, for instance, > > > > > > i915_load="YES" > > > > Right. Mine (rc.conf) has drm_load="yes" and radeon_load="yes". The > > first is supposed to be automatically loaded by the second but I leave > > it there to remind me of the process because it won't hurt at all. > > > > > I have all the required wlan, drm etc there. > > > > Me too. > > > > > And you can also load the drm modules manually on console using > > > 'kldload i915'. > > > > Right. > > > > > This means that, for instance, if I choose to load the drm driver > > > manually then I'm in the pre-drm stage until I will have kldloaded it, > > > say, on console, manually. The copyright note (the "Regents" screen > > > you mention), this is the kernel starting to load. This is pre-drm, > > > there is no drm driver anywhere. This is either VGA or the UEFI > > > display. The terminology "kms_columns" is misleading; that variable is > > > read by the system to try to figure out column x row configuration, > > > but there is no drm driver anywhere. That same "kms_columns" is also > > > read later by the drm driver to set the column x row configuration. > > > > That's what mesmerizing me; suppose the following: > > > > I am booting @ 1920x1200 as set by the uEFI framebuffer code and then > > while booting the kernel the REGENTS message follows (and seems lower > > resolution due to the font scaling you mention but actually is at > > 1920x1200) and then I end up at the root prompt still at 1920x1200 with > > font scaling enabled @ 80x25 characters and without any drm driver at > > all because when I booted I did not instructed the loader to use > > anything out of the ordinary as advised by the man pages and/or the > > handbook and/or whatever, and then, and only then I manually load the > > DRM drivers with kldload drm and kldload radeon and when I issue > > kldstat it shows them
