For this particular case though most if not all countries that have "loser pays all" this would not be a civil matter at all, it would be a matter for the consumer rights agency of the government and such cases are 100% free.
Why not sue if you have a 90% chance of winning? Since the loosing part pays you as the little guy have no problem loaning money to match that 30k spent by the defendant. I have heard of very little "the poor and middle calls can't seek justice" in my country which have loser pays all rules for civil suits. What have happened though is a few cases where people really didn't understand the rules and where shocked when they lost and had to pay the other sides costs.
It's still a upgrade-tool and it still does not check that the available versions are "correct". Of course since the first post he have now changed the tool to do just that so this is all moot but you are still wrong. Yes there is no auto-update tool but here is a upgrade tool just like I wrote to begin width, hardly ignorance my friend!
So Microsoft have now reached a level where the whole Visual Studio suite is 100% bug free so any problems what so ever must always lie with the user. Never thought we would see that day coming ever.
No, first the boot loaded runs (grub, grub2, lilo and so on). Then the kernel is run, and then (if available) initramfs runs. The initramfs is needed on most systems because mounting root (i.e / ) is not always a simple affair, you could run it on some exoteric filesystem, or on some kind of raid device, or some LVM device or even networked via nfs and so on.
And no one want to bloat the kernel with support for all of that shit so instead a small initial filesystem that can be run from memory (hence the name) is often created by the various distributions and put on on the same partition as the kernel (i.e/boot) these are created dynamically whenever you upgrade the kernel on your machine in order to support the configuration that you have.
Once the scripts and applications in the initramfs have been able to mount root (becuse how could the kernel even load for example systemd from the disk before it could mount it!) the kernels work is done and now it calls/sbin/init which could be sysv or systemd or any other init system.
Now according to the screen shot from the summary the systems break before root could be mounted so there is no systemd involved at all since it could not even have been loaded yet. This is also why the boot have been dropped to busybox, since root cannot be mounted there is no way for the kernel to load/bin/bash or even/bin/sh so to still be able to present a shell most versions of initramfs includes busybox (since it's so small and also contains most of the useful utilities).
So yes systemd (or any init for that matter) runs first when we are talking about the userspace world but there happens a lot before we enter userspace.
No one has ever dismissed that systemd could cause some systems to break, that is only an illusion kept by you anti systemd trolls. It falls naturally that no software project is ever 100% perfect and bug free. But you pretend that systemd where the only change when you upgraded when the reality where that every single piece of software on your machine where changed.
And this is the main problem with all of this because there are not a single distribution out there that only introduced systemd, they all did it with together with tens of thousands of other changes. So each and every borked system have to be examined before blame can be issued to who or what caused it.
And also in the real world outside Slashdot the vast majority users of Debian, Ubuntu, RHEL and so on got their systems upgraded to versions that run systemd and none of them noticed a single issue. That is not the same as no one experienced problems with systemd.
Please tell me where I put the blame on two different things? In fact I don't put the blame on anything, all I point out is that it breaks inside initramfs which is way way before any init system (sysv or systemd) is even called by the kernel. I have also pointed out that since initramfs is usually different between distributions this could very well be a problem only on Ubuntu systems, or they could be a problem for people with specific types of hardware since the main thing with initramfs is to mount the root device regardless of setup and from the provided screen shot we can clearly see that this is what breaks (i.e the mounting of root). How do you even propose that the kernel could load systemd from root before it even can mount root?
Because there is no Ubuntu version available without systemd that also can run this new version of the kernel? I can guarantee you that if the person from TFA replaced systemd on his machine with sysv then it would still not boot, you know why? Because it freaking breaks before any init is called by the kernel at all. All you comment tells me is that the anti systemd trolls are completely clueless on how Linux works or how these things stick together.
There is no latest version of initramfs since each and every distribution have created those from scratch in order to support the various and special use cases they each need. Some work to unify it between distributions have been done as far as I know but how far that have gone I don't know.
No it's not past that point, the problem is clearly that it cannot mount root and mounting root is done inside initramfs and before an init like systemd is set up, there is probably some udev inside initramfs as seen from the screen shot but that is not the systemd-udev.service one since that is started only after root is mounted. No this has something to do with mounting the users drives, perhaps they use some form of lvm or raid that is makes this version of the kernel incompatible with the initramfs from Ubuntu (might also be for more distributions but we do not know yet).
Yes it does help because you have access to a shell via busybox so if you know your way around that then you can mount everything manually. Or atleast try:-). But as LichtSpektren already commented you can simply hold in left shit during boot to get to the "select kernel to boot" screen in grub and choose the previous version of the kernel that worked and boot with that.
No it breaks in initramfs which is clearly shown in the provided screen shot (also the fact that it dropped to busybox is an indicator of this) which is long before any init (i.e systemd) is executed.
It breaks in initramfs which kind of is in the kernel. Since the kernel must have a way to mount root before it can begin to even find init (i.e systemd in this case) most distributions use an initramfs that does all that magic before the real userspace (i.e init) is called and they often include busybox so that you can recover from a failure in initramfs if it cannot mount root. The magic comes due to having to be able to mount all kinds of kinky roots (lvm, raid, different filesystems, nfs and so on).
So it appears that for the affected people this kernel version broke something that their initramfs needed. If it hade broke down in userspace then you would get a bash or sh shell and not a busybox.
udev has not been taken over by systemd, since the same developers maintained both the systemd and the udev trees they simply merged them to have a more sane development environment. And the problem from TFA is clearly happening long before the kernel even executes any init since it happens inside initramfs, the mere statement from the summary that the shell is dropped to Busybox should tell you that this happens before even the root is mounted (and root is mounted long before the init is called since the init lives in the root).
Reminds me of all those posts claiming that systemd broke their systems when they upgraded to Debian 8, like there where not tens of thousands of packages that where changed between Debian 7 and 8...
Looking at the screenshot from the summary shows that the error occurs in the initramfs so this happens long before any init is called by the kernel. That it dropped to busybox in the first place was a big indicator that this happened long before init was called.
systemd does not have a registry, it as you point out uses a configuration format that looks like the old MSDOS ini files. The problem exists with the registry, not with the ini files (Lots of other applications uses ini file style configuration syntax).
Slashdot Mirror
Actually quite surprised about this myself, well some day he simply will rip off the wrong guy. If he keeps on doing this it's inevitable.
For this particular case though most if not all countries that have "loser pays all" this would not be a civil matter at all, it would be a matter for the consumer rights agency of the government and such cases are 100% free.
Why not sue if you have a 90% chance of winning? Since the loosing part pays you as the little guy have no problem loaning money to match that 30k spent by the defendant. I have heard of very little "the poor and middle calls can't seek justice" in my country which have loser pays all rules for civil suits. What have happened though is a few cases where people really didn't understand the rules and where shocked when they lost and had to pay the other sides costs.
It's still a upgrade-tool and it still does not check that the available versions are "correct". Of course since the first post he have now changed the tool to do just that so this is all moot but you are still wrong. Yes there is no auto-update tool but here is a upgrade tool just like I wrote to begin width, hardly ignorance my friend!
That the upgrade tool doesn't already do this is actually the strange part in all of this.
So how can you be so sure that the problems that Elledan is experiencing with VS2015 is his fault and not that of the product in question?
So Microsoft have now reached a level where the whole Visual Studio suite is 100% bug free so any problems what so ever must always lie with the user. Never thought we would see that day coming ever.
Why buy that when you can get it for free from your coach?
No, first the boot loaded runs (grub, grub2, lilo and so on). Then the kernel is run, and then (if available) initramfs runs. The initramfs is needed on most systems because mounting root (i.e / ) is not always a simple affair, you could run it on some exoteric filesystem, or on some kind of raid device, or some LVM device or even networked via nfs and so on.
And no one want to bloat the kernel with support for all of that shit so instead a small initial filesystem that can be run from memory (hence the name) is often created by the various distributions and put on on the same partition as the kernel (i.e /boot) these are created dynamically whenever you upgrade the kernel on your machine in order to support the configuration that you have.
Once the scripts and applications in the initramfs have been able to mount root (becuse how could the kernel even load for example systemd from the disk before it could mount it!) the kernels work is done and now it calls /sbin/init which could be sysv or systemd or any other init system.
Now according to the screen shot from the summary the systems break before root could be mounted so there is no systemd involved at all since it could not even have been loaded yet. This is also why the boot have been dropped to busybox, since root cannot be mounted there is no way for the kernel to load /bin/bash or even /bin/sh so to still be able to present a shell most versions of initramfs includes busybox (since it's so small and also contains most of the useful utilities).
So yes systemd (or any init for that matter) runs first when we are talking about the userspace world but there happens a lot before we enter userspace.
No one has ever dismissed that systemd could cause some systems to break, that is only an illusion kept by you anti systemd trolls. It falls naturally that no software project is ever 100% perfect and bug free. But you pretend that systemd where the only change when you upgraded when the reality where that every single piece of software on your machine where changed.
And this is the main problem with all of this because there are not a single distribution out there that only introduced systemd, they all did it with together with tens of thousands of other changes. So each and every borked system have to be examined before blame can be issued to who or what caused it.
And also in the real world outside Slashdot the vast majority users of Debian, Ubuntu, RHEL and so on got their systems upgraded to versions that run systemd and none of them noticed a single issue. That is not the same as no one experienced problems with systemd.
Please tell me where I put the blame on two different things? In fact I don't put the blame on anything, all I point out is that it breaks inside initramfs which is way way before any init system (sysv or systemd) is even called by the kernel. I have also pointed out that since initramfs is usually different between distributions this could very well be a problem only on Ubuntu systems, or they could be a problem for people with specific types of hardware since the main thing with initramfs is to mount the root device regardless of setup and from the provided screen shot we can clearly see that this is what breaks (i.e the mounting of root). How do you even propose that the kernel could load systemd from root before it even can mount root?
Because there is no Ubuntu version available without systemd that also can run this new version of the kernel? I can guarantee you that if the person from TFA replaced systemd on his machine with sysv then it would still not boot, you know why? Because it freaking breaks before any init is called by the kernel at all. All you comment tells me is that the anti systemd trolls are completely clueless on how Linux works or how these things stick together.
There is no latest version of initramfs since each and every distribution have created those from scratch in order to support the various and special use cases they each need. Some work to unify it between distributions have been done as far as I know but how far that have gone I don't know.
No it's not past that point, the problem is clearly that it cannot mount root and mounting root is done inside initramfs and before an init like systemd is set up, there is probably some udev inside initramfs as seen from the screen shot but that is not the systemd-udev.service one since that is started only after root is mounted. No this has something to do with mounting the users drives, perhaps they use some form of lvm or raid that is makes this version of the kernel incompatible with the initramfs from Ubuntu (might also be for more distributions but we do not know yet).
Since it breaks in initramfs and each distribution have their own version of that, this does indeed sound like a Ubuntu specific issue.
Sounds like you have no clue considering the info in the provided screen shot in the summary.
Yes it does help because you have access to a shell via busybox so if you know your way around that then you can mount everything manually. Or atleast try :-). But as LichtSpektren already commented you can simply hold in left shit during boot to get to the "select kernel to boot" screen in grub and choose the previous version of the kernel that worked and boot with that.
No it breaks in initramfs which is clearly shown in the provided screen shot (also the fact that it dropped to busybox is an indicator of this) which is long before any init (i.e systemd) is executed.
It breaks in initramfs which kind of is in the kernel. Since the kernel must have a way to mount root before it can begin to even find init (i.e systemd in this case) most distributions use an initramfs that does all that magic before the real userspace (i.e init) is called and they often include busybox so that you can recover from a failure in initramfs if it cannot mount root. The magic comes due to having to be able to mount all kinds of kinky roots (lvm, raid, different filesystems, nfs and so on).
So it appears that for the affected people this kernel version broke something that their initramfs needed. If it hade broke down in userspace then you would get a bash or sh shell and not a busybox.
udev has not been taken over by systemd, since the same developers maintained both the systemd and the udev trees they simply merged them to have a more sane development environment. And the problem from TFA is clearly happening long before the kernel even executes any init since it happens inside initramfs, the mere statement from the summary that the shell is dropped to Busybox should tell you that this happens before even the root is mounted (and root is mounted long before the init is called since the init lives in the root).
Reminds me of all those posts claiming that systemd broke their systems when they upgraded to Debian 8, like there where not tens of thousands of packages that where changed between Debian 7 and 8...
Looking at the screenshot from the summary shows that the error occurs in the initramfs so this happens long before any init is called by the kernel. That it dropped to busybox in the first place was a big indicator that this happened long before init was called.
Because the top models with the best display panels have Smart.
systemd does not have a registry, it as you point out uses a configuration format that looks like the old MSDOS ini files. The problem exists with the registry, not with the ini files (Lots of other applications uses ini file style configuration syntax).
yeah because it was that hard to understand that it was supposed to be "do not". What are you, a PowerShell parser?