short lengthy and vaguely related story about an SSD
It all started a few years ago, when I was just starting to work at Red Hat. SSDs were all the hype, but although promising, they were also pricey and feared of due to (IMHO unrealistic) MTBF concerns. Being a bit of a gadget freak, I liked the potential of the SSD and the promise of shorter read/write time. My first one was a 30GB Kingston SSDNow, which albeit rather slow compared to todays models, did deliver the promise and is still working until this very day (~4 years and counting).
Anyway, having a laptop from work I decided to ask my boss if it’s possible to get an SSD, seeing as I had a very good experience with it at home. Her reply was along the lines of “Sure, talk to our IT guy and see whats the procedure”. I went to the IT guy and asked him “Kind sir, how is it possible to get an SSD around here?” and in turn he replied “You know what, I have one lying around here which I was testing, you can have it”. Joy ensued as I had a new SSD for the work computer. It was a Lenovo branded one, which is logical since we use Lenovo computers.
I went on to install the SSD and again the difference was quite noticeable, Fedora booted faster, eclipse worked better, maven compiled like a champ, life was sweet. This was about two years ago, until now..
A few weeks ago I received my brand new Samsung Pro 840 SSD from work. I will be receiving a new laptop soon, and a new SSD instead of the Lenovo one I currently have sounded like a good idea so I went to my boss again and asked her “Tell me, is it possible to get a new SSD”, to which she replied “Well, we already spent the hardware budget, but I’ll see what I can do”. A week later the budget was approved, and the order went out. I chose the 840 as it seemed like a good one based on reviews, benchmarks, and it seemed like it would fit in the laptop I should be getting.
So what does it have to do with Fedora 19?
Well, seeing as on the last SSD I had Fedora 16 installed, I decided a new drive would be a good time to “upgrade” (also the development environment were working on works better on latest Fedora with latest packages). I didn’t clone the old SSD to the new since I’m not sure what support for SSD is put in place during install (from what I know it should be rather stable now) and also the size of the new drive was 2x larger.
I grabbed the Fedora 19 live ISO (being the advocated format) and created a live USB using the Linux Live USB Creator tool, swapped the drives and booted into “Live” mode where you have a choice either to experiment with the system or install to drive immediately. I chose the immediate option to install and followed the simple steps. After a few minutes the installer proclaimed it was done and that I should reboot, so I did.
At first everything worked, which quite amazes me every time since, while being very nice, Fedora isn’t a very stable OS (don’t try FedUp for example, unless you’re literally fed up with your OS and want to corrupt it, possibly.. I heard some people did have success with it, meh).
Fedora 19 tips & tricks
A few changes took place that I think are worth a mention:
- The notifications area is in the bottom of the screen and appears if you press “Win” + M, or scroll the mouse down to the screen border, and then keep scrolling until it appears.
- Changing the language is done via “Win” + Space combo, which is not that bad actually.
- The CUPS service has split into a “server/client” bundle, so if you want to browse CUPS automatically you now need to:
echo BrowsePoll server.example.com >> /etc/cups/cups-browsed.conf systemctl enable cups-browsed.service # To have the daemon start on boot systemctl start cups-browsed.service # To start the daemon immediately
- Install and use gnome-tweak-tool to adjust some basic settings which are hidden in the regular config.
- If you use eclipse, or just don’t like them, you’ll probably want to disable “Ctrl” + “Alt” + “Up”/”Down” combo but this can only be done from command line, since the UI config tool doesn’t show all the combos (for moving one desktop up/down):
dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-up "['Page_Up']" dconf write /org/gnome/desktop/wm/keybindings/switch-to-workspace-down "['Page_Down']"
Happy after doing all the setting and tweaking I shut down the laptop.
Dracut.. It should be named Dracu
tla with all the time it sucked from me
Next day, it wouldn’t boot. “What, defective SSD? Are all those ghost stories true? Can’t be!” I thought to myself.. But the hard cold fact was that Fedora was throwing me to the dogs! I tried everything I could think of (at the time): swap back to the old SSD – it boots, swap to the new – it doesnt; Google – nothing of interest here; Launch live fedora – drive looks fine; fsck – all green; Reinstall Fedora – now it boots..
Well, weird but what can I say? Second time’s the charm?
Apparently not, since not an hour passed and it wouldn’t boot again. Until I notice something bizarre… When booting, if I’d plug the live USB back in it would boot, That’s weird.. What does the live USB got to do with it? Well apparently quite a lot, and then again nothing at all.. I rebooted a couple of times just to make sure and indeed with the USB plugged in it boots, but without it it doesn’t.. Seems like some sort of love affair between the two flash-based devices…
Well, after googling quite a bit I found the real culprit – Dracut! Seems that when using the Live USB (probably because it was created in LiLi?) there’s a swap partition on the USB itself, which is mounted and used by the live system. Sometime during the installation process, dracut is used to create an initramfs image for the new OS, unfortunately this image also contains a trace of the USB swap partition and this causes it to expect it to be present when the OS is booting, or fail the boot if not.
So what can you do?
Well there are a couple solutions which will work:
- Don’t install from Live USB (perhaps it’s related to how you create it, I’m not sure). There are many flavors of Fedora that will work and not make you curse it.
- If you did install and hit this problem, you can take the following steps:
- Remove the live USB swap entry from the /etc/fstab file (identified by UUID)
- Remove the swap from being used: swapoff (just to be safe)
dracut -H -f --regenerate-all --fstab
- Now you can safely remove the live USB and not worry about it any more.
Now it’s really a happy end!