Puppy Linux Discussion Forum

It's not necessary, but someone may want to read this thread for additional context:
viewtopic.php?p=121253

DebianDog-Bullseye-20201127 refused to install on sda1 but for some mysterious reason accepted sda2. Both are formatted with the BTRFS so it doesn't make sense. But sda2 is not sustainable for me. It has very little free space. So I tried this trick.

I am booting Debian Dog with this Grub entry:

menuentry "DebianDog.iso" {
  insmod ext2
  linux (hd0,2)/live/vmlinuz1  from=/ noauto changes=/live/changes video=SVIDEO-1:d 
  initrd (hd0,2)/live/initrd1.xz
}

So I copied the /live directory across partitions and changed the Grub entry:

menuentry "DebianDog.iso" {
  insmod ext2
  linux (hd0,1)/live/vmlinuz1  from=/ noauto changes=/live/changes video=SVIDEO-1:d 
  initrd (hd0,1)/live/initrd1.xz
}

Same thing, only different partition, (hd0,1).

Debian Dog booted, but I installed something to it and rebooted into another Linux (the one I'm using right now).
Checking the /live directory in both partitions, it is clear that changes were applied to sda2 although it booted off sda1. I know because I saw (hd0,1) in the boot sequence output.

Well, the /live directory in sda1 is a copy of /live in sda2 so I have to assume there is something in there that still points to sda2. Do you people what that is? I want to hack it and have Puppy running on sda1. I don't have other choices.

Best asked on the debiandog SubForum, https://www.forum.puppylinux.com/viewforum.php?f=46. While this, the Puppy Linux Discussion Forum, supports any portable, modular operating system, its primary focus is Puppy Linux. These are created using Woof. DebianDogs are not. IIRC, they are created beginning with a debian 'net-install', then fashioned to work similar to Puppys; the operative term being similar.

If you don't get an answer to your question:
since DebianDog-Bullseye-20201127 (a) boots from sda1 and (2) you aren't going to use the version on sda2 for anything I'd delete everything from sda2 AND the live/changes directory on sda1 in order to create a new live/changes directory, starting from scratch.

Topic moved to "DebianDogs" as requested...

Mike.

@Luluc
First, always make sure that there isn't same folder name ("live" in your case) on two different partitions as it may conflict with each other.
To be on the safe side it's best to create a folder with unique name, let's say "bulls_eye" and move the "live" foider in there (so you get /bulls_eye/live)
Also it may be best to use UUID , example: (replace the large uuid string (also at from= and changes=) with what blkid gives you for the partition containing "bulls_eye/live")

menuentry "Bullseye (in bulls_eye)" {
insmod ext2
search --no-floppy --fs-uuid --set=root 34b10665-11c5-493c-9bff-f4f1e7db86f2
linux /bulls_eye/live/vmlinuz1 noauto from=UUID:34b10665-11c5-493c-9bff-f4f1e7db86f2/bulls_eye/ changes=UUID:34b10665-11c5-493c-9bff-f4f1e7db86f2/bulls_eye/live 
initrd /bulls_eye/live/initrd1.xz
}

No need btw to specify "bulls_eye/live/changes" , "bulls_eye/live" is enough, the changes folder will be automatically created there.
edit: you can also point your changes to another partition using uuid, e.g. changes=UUID:<long-uuid-string>/ (then the changes folder will be at the root of that partition)
edit: can't comment on using BTRFS and encryption, I never used it.
edit: probably the installer does not have real support for BTRFS, that could explain why it fails to install to sda1.

fredx181 wrote: ↑Sun Jun 02, 2024 10:42 am

edit: probably the installer does not have real support for BTRFS, that could explain why it fails to install to sda1.

That is not the reason. I found out the reason and reported it in my other thread:
viewtopic.php?t=11698

Luluc wrote: ↑Sun Jun 02, 2024 12:49 am

I solved the mystery.

It turns out I am not booting off a CD or pen drive. I am booting off ISO images stored on sda1 right from Grub. That causes DebianDog to boot with sda1 mounted. Then I guess the installation script cannot understand that. When it tries to mount sda1 to copy the persistence data over, it certainly gets some error because sda1 is already mounted, and the script fails.

I solved it by moving the ISO image to sda2 and updating the Grub entry accordingly. Then DebianDog installed on sda1. Even though sda1 is BTRFS. Come on, people. BTRFS is nothing new. It's pretty awesome too.

Anyway, on the first boot it still booted into the sda2 persistence data! What in the world??!!

So I deleted the persistence data on sda2 and rebooted, and everything finally worked the way I wanted. Well, almost. I am still on a naked partition, no encryption. That sucks.

BTRFS is nothing new. It's pretty awesome too.

Yes it has been around.....but had many bugs and was not stable until recently. Since Puppy Linux basic design using a save folder or save file already has a "rollback" function of sorts and a snapshot feature already in pupmode 13 with save persistence changes on command, it wasn't (isn't) pressing enough to develop using it more.

rockedge wrote: ↑Mon Jun 03, 2024 3:05 pm

BTRFS is nothing new. It's pretty awesome too.

Yes it has been around.....but had many bugs and was not stable until recently.

Not true, only on RAID. I have been using it for 8 years, never had a problem. I've had data loss multiple times on ext3, ext4 and xfs. Only once on btrfs because of a hard reset.