@ptesarik @oleksandr I also meant the forks of firefox or the ground up new browsers, but it's too fragmented and unusable indeed.
0
0
0
@ptesarik @oleksandr What do you mean no alternatives? There are at least 17 other browsers to choose from!
1
0
0
kdave
kdave
https://git.kernel.org/linus/006568ab4c5ca2309ceb36fa553e390b4aa9c0c7 Adding Link: tag to the original discussion is ok but it should not be instead of a proper changelog, namely when there's discussion what exactly is the fix actually doing. Also it's for out of tree module. And it got a CVE.
0
0
1
@ffmancera You should not skip 42 for reasons that only Univese can understand.
1
0
2
kdave
kdave
Have some fun, take C keyword quiz https://www.jetpunk.com/user-quizzes/1363547/c-keywords-quiz
1
0
0
@ffmancera @ljs Now imagine what offers get people contributing to crypto/
0
0
3
@ptesarik @vbabka @oleksandr Sector sizes of block devices yes, because of block layer abstraction. Not on the filesystem level unless you want more OMG blatant layering violation.
0
0
2
@vbabka @oleksandr one dd back and forth was easier on first sight. I can try again with manual partitioning though.
1
0
1
@oleksandr @vbabka I don't know but I assume this works, fdisk would create partitions at the right places and filesystem uses logical disk address.
0
0
0
@oleksandr @vbabka So, it's not that simple.
What I did:
1. dd device to file
2. format NVMe to 4096 bytes/sector
3. dd file to device
4. no partitions detected
5. reboot, stuck in BIOS
Attempt to copy parition table from file to device using sfdisk showed errors and sector size of 4096, GPT table wrong number of sectors etc.
In the log there was line like "inconsistent atomic write size, namespace will not be added subsystem=4096bytes controller/namespace=512 bytes".
Recovery:
1. boot rescue system
2. format NVMe back to 512 bytes/sector
3. dd file to device
4. partitions detected again
5. reboot, back to the system
I don't know what exactly went wrong, the sfdisk partition recreation worked fine with Kingston (KC3000). There are potential problems with partitions and some kind of mismatch what drive reports as sectors.
What I did:
1. dd device to file
2. format NVMe to 4096 bytes/sector
3. dd file to device
4. no partitions detected
5. reboot, stuck in BIOS
Attempt to copy parition table from file to device using sfdisk showed errors and sector size of 4096, GPT table wrong number of sectors etc.
In the log there was line like "inconsistent atomic write size, namespace will not be added subsystem=4096bytes controller/namespace=512 bytes".
Recovery:
1. boot rescue system
2. format NVMe back to 512 bytes/sector
3. dd file to device
4. partitions detected again
5. reboot, back to the system
I don't know what exactly went wrong, the sfdisk partition recreation worked fine with Kingston (KC3000). There are potential problems with partitions and some kind of mismatch what drive reports as sectors.
2
0
0
@oleksandr @vbabka And I have the first victim, Verbatim Vi3000, system does not boot, device is visible in BIOS.
1
1
2
@oleksandr @vbabka My sample is too small to tell, I have converted Kingston drives, one of them is backing drives for testing VMs, so I'll know when it fails.
1
1
1
@vbabka @oleksandr Probably a firmware bug, that do exist and happen on all devices / vendors and are unfortunatelly not that rare.
0
0
1
@oleksandr @vbabka Yes, basically two commands: nvme ns-id -H /dev/nvmeX (check the profiles) and nvme format --lbaf=1 /dev/nvmeX to change it. Obviously, it destroys the data.
1
0
2
kdave
kdave
NVMe's are formatted to 512B sector size, and most of them have option to be formatted to 4096. And it works. I'm amazed.
1
0
2
kdave
repeated
repeated
Lorenzo Stoakes
ljs@mastodonapp.ukAlways remember the register is a trash publication that publishes straight up lies to suit the author's bias.
Their kernel shit is worse than the usual tripe you see in the press (LWN being a massive exception to that of course!)
0
1
1