AFAIK /boot is a static directory once installed, so no need for the journalling features of ext3 or ext4.
I get that, but there must be more improvements of ext3 and ext4 over ext2 than just journaling. Also recent kernels support journal-less mode in ext4.
Nothing worth the wasted space to a static partition that could even be made read-only in many setups, AFAIK.
I’ve tried that. And I reverted to “ext2”.
Here’s the problem with “ext4” without a journal:
A new opensuse version comes out. So I install. I use “import partitioning” to reuse the same partitions.
If I use “ext4” for “/boot” then I have to remember to go through the settings to tell it to not use a journal. If I use “ext2”, it defaults to continuing to use “ext2” and thus no journal.
“Old habits die hard” and my ext2 boot partition has never failed, even on my one failing HDD where the errors started on a root partition (ext4). Given the size of HDD’s now, although kernels also increase in size, a 1GB boot partition on ext4 makes little difference overall and should provide some future-proofing (my 500MB ext2 is far from full).
I wasn’t aware of support for “journal-less mode in ext4”, so thanks. I could upgrade when next re-partitioning window arises, so what are “more improvements” apart from ext4 being currently maintained?
Just an update.
I installed grub2-2.02~beta2-197.5.x86_64 (thanks M. Chang) with its dependencies in a “troubled” setup:
- Win*VISTA on sda1 starting at sector 63
- BTRFS root/ on logical partition, no separate /boot.
Updating the GRUB configuration via Yast-bootloader with “boot from root partition” and “Generic to MBR” is good with no errors
(boot.img and core.img installed in the few sectors at the beginning of the BTRFS partition, all installed OSs boot regularly).
However, looking at pbl.log, it seems to have done nothing different from the original grub2-2.02~beta2-20.5.1.x86_64 run from within the running system.
So the real difference should be a clean install with a snapshot, but we may have to wait a little more according to this thread
Tumbleweed ISO questions - Install/Boot/Login - openSUSE Forums
perl-bootloader simply calls grub2-install. Patch changed nothing in how yast or perl-bootloader work. If you install from network you should have current grub2 package with patch.
This does not work for me. 
I have a Dell laptop that came with three partitions (as usuall for Dell, sda1 and sda2 are small partitions for recovery and diagnose tools, and sda3 with Windows 7 on it). Suse install shrank sda3 and placed root in a logical partition. At the end of the installation I always get “Grub2” failed to install, unless I opt to have the root partition formatted with ext4.
Did I understand this thread correctly? There is no workaround to this issue, beside having another ext2/3/4 partition?
No You do not have to have a separate non BTRFS boot.
BUT If you hibernate or use the boot to other OS option on shutdown then you do need one. The reason is the in those circumstances then Grub needs to write to a file in the boot partition and it does not know how to write to BTRFS. Oopsie
This is a known problem for some time. But it either was not fixed or the workaround does not work I suggest that if you really don’t need the bells and whistles and want to avoid problems with BTRFS in fairly common circumstance then use ext4. Nothing wrong with it it ain’t broke and you won’t see the problems that BTRFS can cause. Of course there is nothing wrong in trying a new FS out and there are some interesting features but for a simple desktop why do you need them??
To be fair, I had the same problem and the first boot didn’t succeed.
I had to rescue the system, switch the “boot” flag to the btrfs partition (it was still on the Win* one), boot the system somehow, then reinstall GRUB2 from inside the running system. No problem after that, even with hibernate or multiboot (there is a workaround script installed by default.
Anyway, I agree with gogalthorp: on a laptop it seems not worth the hassle…
Okay, I was very excited about the snapshot feature, since online updates frequently break my system (no graphics, no cups, no keyboard, no sound, I had them all break in the past years due to Yast online updates). “Laptop” might be the wrong word, it’s more of a portable desktop machine. It is my one and only computer, usually operated in docking station of which I have four in various locations.
I know, I should resist updates by now, but there are still several applications that have annoying bugs and there is always a fix promised here and there by updates. Hope dies last.
So I guess I’ll have stick to EXT4 then, since I am uncomfortable to do my own partitioning nowadays, after I have seen all those “subvolumes” that the installer suggests. I would not be able to recreate them all and I don’t even know what they are for.
You made the point for me. with a a good example. “Simple desktop” (mine is fairly simple) or “Laptop” is not really the right yardstick. It’s what one applies to the system, how often changes occur, and the required ease of recovery that matters here. I’m interested in “snapshots”, in particular the Pre-Post variety for YaST and zypper applied changes, because I run Tumbleweed. If I ran standard openSUSE with lots of changes using oBS repos, it could also be useful for rollback.
So I guess I’ll have stick to EXT4 then, since I am uncomfortable to do my own partitioning nowadays, after I have seen all those “subvolumes” that the installer suggests. I would not be able to recreate them all and I don’t even know what they are for.
Don’t worry about the “subvolumes”, they are there to prevent those directories from being included in snapshots. When I first installed btrfs on 12.3, snapper and the subvolumes were included by default, and IIRC there were no details given in the installer. As usual someone on the mailing list said that it should include a warning and the ability to reconfigure. Once the defaults get accepted, one doesn’t need to bother again.
Because I multiboot, I keep /home onboard the root file system to preserve the system settings, and keep my data in a separate partition. To prevent snapshots of my /home e.g. it will sometimes contain large downloaded static files, I just add it as a subvolume using YaST Partitioner’s built-in feature. I guess that could also be done with the installer at the beginning.
Rolling back may not be as simple as you think. It is nice to say I’ll just roll back but exactly what are you rolling back??
Say package A is installed and is updated but the update breaks something. Do you roll back ALL changes to the partition including any databases you might have been using that live in root or other packages installed etc. Or just the changes to the package A and if just to package A what files?
On the other hand I can simply go toYast and select versions and drop back to the previous for package A maybe locking updates for it for a while.
Think about it. Some time a simple concept is not really so simple
Now you’re a mind reader. You don’t know what I think! Oh, I see a hypothetical situation about to be conjured…
That’s why there are two snapshots Pre- and Post. Snapper allows you to see what files have been changed and also the differences between two versions of a file. You don’t have to completely revert. You can select specific files to roll-back.
Your method only deals with package changes. What about configuration file changes?
Still think it is a lot of fiddly bits. I personally have never had the need. If you had a nice GUI that allowed you to select a package and roll back all the files including configs. ok maybe but you can’t expect the knowledge to roll back to be understood by most users.
Yes config files can be changed also which just makes the web deeper. Sure maybe you know what files to roll back but does the guy that just moved from Windows know? So why should he have to suffer the odd little BTRFS problems when things don’t boot right after a hibernate and such things when they don’t really know how to actually roll things back.
Really I have nothing against BTRFS think it may be a great commercial file system but I think that it is overkill for the average user. ie always follow the K.I.S.S principle. BTRFS should be available to those that want or need it but should not be the default. Sorry it is just a bad idea. I mean not all the features promised are available yet. So why is a partially finished FS being set as default. Ok it works and seems over all for what is available stable. Does that mean we should foist it on unsuspecting newbees. :sarcastic:
Of course there will likely be many users who will regard it as too “fiddly”. Yes, YaST includes the snapper GUI, whether nice or not is a personal thing. You select a snapshot (Post-) to review the displayed file changes, so you are then working at the file level unless you choose to rollback all changes.
So why should he have to suffer the odd little BTRFS problems when things don’t boot right after a hibernate and such things when they don’t really know how to actually roll things back.
In the case of the hibernate problem, reading documentation and following advice could have avoided it. Yes it requires some planning and research for those new to btrfs. At least the documentation was available well before it became openSUSE’s default. I’ve also seen a snapper tutorial, and there is probably a video on Youtube although I haven’t checked recently.
My point was that “simple” desktop or even “average” is the wrong target. The openSUSE Members chose their target user after the last consultation on project strategy, and it doesn’t include words like those. Btrfs as non-default has been out there for the extended release interval this time. Perhaps it has seen more rapid development than previous file systems. On balance I still think it’s too soon to be the “default”, owing to current performance and unsubstantiated user take-up or need.
I’m not aware of any documentation regarding the “hibernate problem”, if this means what I think it means.
The problem that grub2 will never show the menu again after hibernating should be “fixed” in 13.2 though, as there is a script called on hibernate/resume which stores and restores /boot/grub2/grubenv (where the entry to boot is saved).
Such a script was already included in earlier versions as well, but it had a bug which broke the restoration of grubenv.
I can’t help that if I think you mean, what I think you mean.
???
I wrote what I think you mean in the following sentence.
Is that what you mean or not? (i.e. that grub2 wouldn’t show the boot menu any more after hibernating, because it cannot reset the entry to boot on a btrfs partition)
This is actually not directed specifically to you, actually gogalthorp started to write about the “hibernate problem”…
Definitely not, and not a reference back to any of your statements in this thread (or mine particularly).
I’ve no reason to doubt your statement(s) on the grub2/boot menu issue. I don’t recall having the “hibernate” problem on previous tumbleweed (Btrfs), but then my ThinkPad only uses it on extremely low battery condition, which is rare. I used it more when “suspend” was broken, but that has worked throughout 13.1, and still does.