.

`.

damned. it should have been enter-tilda-^b :-)

would you like to tell about your cat walking over the keyboard? :)

denk: the only cat i have is /bin/cat :-D

yuripv: but i've got some Big Scary Daemons here. :-)

I was trying to find out why ioctl fails in format I have this termbin.com/cwif that traces ioctl return values; and the function where it's called termbin.com/hy6d

but now I'm searching what the return values means for the ioctl, or I'm missing something? . Basically I'm trying to find out why a disk appears as unformatted in oracle cloud.

arg1 should be an errno (arg0 is an offset into the function where the return occured)

So that one that returns 25 is ENOTTY 25 /* Inappropriate ioctl for device */

and scsi_rdwr is returning -1

that is reading the input though, so unlikely to be interesting

the only one that makes sense is at the bottom, is in the is_efi_type()

andyf where did you find the ENOTTY value ?, is odd that returns 25 as that scsi_rdwr tries to write 4 bytes to check if the disk is formatted

/usr/include/sys/errno.h

But as yuripv notes, is_efi_type() is returning EIO

Have you tried `format -e` at all and tried to write a fresh EFI label?

andyf with format -e returns the following termbin.com/z49w3

yuripv I'll check is_efi_type

yuripv is_efi_type returns 0 checking it with dtrace, is that correct for virtioscsi ?src.illumos.org/source/xref/illumos…md/format/startup.c?r=dcc43656#1796

Here is the output for scsi option in format, maybe someone more knowledgeable sees something strange termbin.com/ncyob

andyf format -e then label returns Current Disk is unformatted.

neirac what device is behind that disk?

tsoome is a virtioscsi AFAIK c1t0d1 <ORACLE-BlockVolume-1.0-46.58GB>

oh ok, its cloud, so you have no idea what is back end (silly me)

so, what does format -> format tell?:)

tsoome termbin.com/uxcu

sort of makes sense.

that scsi_rdwr() returns -1, but I guess you figured that already

tsoome and is_efi returns 0

is_efi() only can return 2 values, and if you look into it, you can see the problem there....

if there was issue with transport, you can not trust the return value from is_efi

tsoome I also tried hardcoding is_efi return value to see how far it got, but I see no changes on the situation

well of course - if you are getting scsi IO failures, you would need to find out the cause for that first

danmcd, andyf: apparently apple are rolling out 2023b (staged), and 2023c isn't out yet

also apparently 2023c makes lebanese daylight savings start on wednesday, not sunday when it originally did, or in april when they tried to.

so that might be a rush job with little notice _as well_ depending on how the tz people do it

Officially I'm not rolling out anything until next week Thursday 0000GMT. But good to know Apple is working with 2023b.

Keeps us on our toes!

I was under the impression that 2023c is a rollback to 2023a

sommerfeld: I thought so too, but I read on the list that what the cabinet actually said was that it starts wednesday now, I didn't know whether eggert was going to keep the few days in the interim for historical purposes

or if it's all such a mess they aren't bothering.

I also love both the whackiness of the "maximum of one release a month" person, and the "We can't possibly choose our timezone with more than 4 weeks notice!" replies.

we had already integrated 2023b before we knew about the coming reversion, but won't have the bits shipped for weeks anyway, so it won't matter much

alanc, sommerfeld: actually, since you're both around and have a lot of historical wisdom: Do you know why we never just put .KEEP_STATE: in Makefile.master?

does it not do what you'd think through inclusion? is there some place we _intentionally_ don't keep state?

I don't understand why we all hold to noon has to be 12ish

One time for everyone and just live at offsets

sjorge: it's because of railways

before then, noon was when the sun was at its highest locally.

but once you get railways, you need everyone to basically agree on what time it is, and everything sucks.

The information super railway

I have an `sdate` program that shows me _actual_ local time

but I always forget it by definition leaks my precise location :)

Ba

*Ha

richlowe: does it take into account the day-to-day variation in local solar noon over the course of the year, or is it just based on local mean solar time?

i'm using a rPI2 with 2 GPS' for time fix and one of them has a PPS source 🤓 cant get more better than that without throwing money at it 😅

richlowe: only half of it

sjorge: I would prefer just switching to TAI all the time

I'd just prefer the clocks to go forward at 4pm on a Friday, if they're going to, not 1am on Sunday.

sommerfeld: I think I did as fully as I could understand the calculations for, but it's been a while

and now I'm worried it's less precise than it could be!

and 2023c is out...

richlowe: I don't know about .KEEP_STATE

richlowe: oh, sorry, I missed the Q about .KEEP_STATE. Not sure about that, either. Worth an experiment but I wouldn't be surprised if there were unintended consequences (additional build churn or racy behavior in parallel builds)